WIP: BatchIt#637
Conversation
|
Looks like it is leaking in some case |
Whoops; I had the loop termination conditions wrong. They're fixed now, I think. Let's see if CI agrees. |
|
After discussions with @mjp41 yesterday, I've introduced a notion of "tweakable obfuscation" and have made all the intra-slab free lists' backwards signatures use the address of the slab metadata as the "tweak". The next step would be to remove the per-thread keys and have everyone use a common global key (probably not |
|
I've (at long last) got things flying end to end with a very simple "cache" on the sending side -- a single open ring -- but I think some review and investigation is a good idea. Here's what |
|
We should:
|
|
Two things to address:
|
|
Just rebasing after #659 landed. Todo-s remain to be addressed. |
|
And the novelty of |
|
Start addressing to-dos, specifically being able to turn BatchIt off: rewrite history to have always had a |
|
OK, well, apparently But that breaks all the 32-bit builds, because I'm not sure why some other Windows builds are still broken. |
|
OK, here's a version with, I think, all todo-s at least prototyped. BatchIt can be turned off (see the "Make BatchIt optional" commit and/or CMakeLists.txt) and it now attempts to play nicely with |
Plumb its use around remoteallocator and remotecache
This prepares the recipient to process a batched message.
Exercise recipient machinery by having the senders collect adjacent frees to the same slab into a batch.
This might involve multiple (I think at most two, at the moment) transitions in the slab lifecycle state machine. Towards that end, return indicators to the caller that the slow path must be taken and how many objects of the original set have not yet been counted as returned.
We can, as Matt so kindly reminds me, go get them from the pagemap. Since we need this value only when closing a ring, the read from over there is probably not very onerous. (We could also get the slab pointer from an object in the ring, but we need that whenever inserting into the cache, so it's probably more sensible to store that locally?)
Move ring set bits and associativity knobs to allocconfig and expose them via CMake. If associtivity is zero, use non-batched implementations of the RemoteMessage and RemoteDeallocCacheBatching classes. By default, kick BatchIt on when we have enough room in the minimum allocation size to do it. Exactly how much space is enough is a function of which mitigations we have enabled and whether or not we are compiling with C++20.
There's no need for a full pointer here, it'd just make the structure larger on CHERI.
In order not to thwart `mitigations(random_preserve)` too much, if it's on in combination with BatchIt, roll the dice every time we append to a batch to decide if we should stochastically evict this batch. By increasing the number of batches, we allow the recipient allocator increased opportunity to randomly stripe batches across the two `freelist::Builder` segments associated with each slab.
|
Rebased after merging #675. Trees are identical, just commit objects differ. |
2 participants
As part of the assessment of #634, but also perhaps more generally useful. Opinions welcome.