Allow carrier migration between different allocator types #1854
Carriers can currently only move between instances of the same allocator type, which causes excessive memory allocation when one type is starved and another has lots of leftovers. This PR lifts that restriction and makes all allocator types share the same "carrier migration pool."
This is transparent aside from changes in how
In an earlier iteration of this PR @ferd asked if this could negatively impact memory fragmentation now that there's no longer a hard barrier between different types, and my reply was a bit too curt. It's a good question, and the long answer is "yes" but we're sure that the effect will be limited.
Carriers inside the migration pool can't be used for allocation, and a carrier is only abandoned and placed in the pool when it's practically empty (user-configurable) in the hopes that we can deallocate it soon. When a carrier is fetched from the pool it won't be abandoned until it's practically empty again, and since allocators prefer the carriers they've abandoned over searching the pool (with some caveats), carriers tend to stick with their allocator unless something drastic happens.
Keeping things separate could of course be better for certain workloads and we're open to adding options to control which types a carrier can migrate between, but it's not a part of this PR.
The text was updated successfully, but these errors were encountered:
This reduces instability on test rigs with more than a handful schedulers.