* Thomas Stüfe:
There is a Fedora discussion under way to eliminate the kernel VMA limit completely, but the kernel OOM handler isn't really compatible with that. The current heuristics do not seem to pick the most appropriate process if the kernel ends up with too much (unswappable?) memory used due to an excessive count of VMAs, so I'm not sure that we're going to change the default.
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal) <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WVWHTLXSGZN4QMAE577ZFZX4ZI6YZF3A/>
Interesting. Thanks for the hint. I have seen us running against this limit several times in the past, and the error is often confusing (e.g. when creating a thread and mprotecting the guard pages, which may split the contained VMA into two; if that fails, the mprotect fails with ENOMEM, which is not intuitive.
That's not great. At this point, it may make sense to engage with the kernel mm developers to see if they have any ideas. Maybe a soft/hard limit (see setrlimit) would make sense: a low-ish default limit to prevent taking down the system if processes go wrong in an unexpected way, and a way to raise it for processes that are known to need more than that. But there could also be performance implications from many VMAs, but the kernel developers would know. Thanks, Florian