Every time the OOM killer mis-aims? 🙃
Quote Tweet
In a way you never do with Linux. Because its design is generic. It’s meant to run programs for you. But when’s the last time it’s memory model got in your way?
Show this thread
1
1
22
Conversation
Every time I want some control over what page sizes are used?
2
6
Every time I want to rearrange virtual space within a process? mremap() 🤮
3
5
Replying to
mremap is super broken because it returns EINVAL if you try to use it on multiple VMAs but the kernel does not reliably merge compatible VMAs.
I have a simple test case involving switching to PROT_NONE and back where it fails to merge them, and then mremap will return EINVAL...
1
1
Look at how painful it was to write this code to remap with guard pages:
github.com/GrapheneOS/har
MREMAP_DONTUNMAP can theoretically be used but I don't think it can expand the size of the mapping so it will be necessary to use mprotect in a way that may lead to non-merged VMAs.
It's the reason this in-place growth code was disabled:
github.com/GrapheneOS/har
It isn't particularly useful anyway, because in-place growth rarely works in practice.
There's separate code above that for in-place shrink.
All of this is needed due to the limitation of 1 VMA.
1
1
This is my test case if you're curious:
gist.github.com/thestinger/8a1
I haven't really bothered trying to get this fixed upstream at this point. It doesn't really help me that much since it would be so long before I could assume that the kernel actually works properly.
1
1
Show replies