The in-place realloc growth path (as opposed to MREMAP_MAYMOVE|MREMAP_FIXED) has such a low sucess rate that I hadn't noticed it's impacted by the kernel missing opportunities for VMA merging. I disabled it for now since the important mremap surfaces it: github.com/GrapheneOS/har.
Conversation
An mremap call fails if the source has multiple VMAs and the kernel often fails to do VMA merging when it should. It also has no way to preserve the source mapping when moving. I can't use it to move anything below the quarantine threshold. In jemalloc, they can't use it at all.
1
If it could move multiple VMAs and expand the last one, it would also avoid needing this in-place growth path in the first place. There could be a single code path for expansion and the moving case would be far simpler instead of a convoluted mess working around this bad API.
1
1
For in-place growth, it has no real advantage of the new MAP_FIXED_NOREPLACE, which is why I tried adopting that and discovered it was broken: patchwork.kernel.org/patch/10634763/. There isn't an alternative to relocate pages efficiently, but it's an awful API for it for multiple reasons...
1
In-place growth rarely succeeds due to mmap best-fit, typical 2x growth factor for contiguous collections (arrays / ringbufs, hash tables) and downwards mmap growth. Causing split VMAs leading to the important mremap failing makes disabling this an easy choice. Not a big loss.