ZGC and 1G pages?
Florian Weimer
fweimer at redhat.com
Mon May 8 10:34:47 UTC 2023
* 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
More information about the zgc-dev
mailing list