<div dir="ltr"><div>Hi Florian,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 8, 2023 at 11:15 AM Florian Weimer <<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Thomas Stüfe:<br>
<br>
> ZGC, on Linux, seems only compatible with 2M pages. Seeing that ZGC is<br>
> often used with very large heaps, is support for 1GB pages planned?<br>
><br>
> Especially if one disregards uncommitting (-ZUncommit), 1G pages could<br>
> be a speed boost for customers with gigantic heaps, as well as reduce<br>
> their number of VMAs.<br>
<br>
Is the number of VMAs really tied to hugepage support? </blockquote><div><br></div><div>Indirectly. AFAIU, the number of VMAs is coupled to the size of an internal granularity ZGC uses to stitch together memory from the underlying memory layer. That granularity is 2M, I assume, because large pages are 2M on the architectures relevant to ZGC. It seems hard-wired. <br></div><div><br></div><div>In long running processes, I observe a dense mixup of these stitchings, so the kernel cannot fold neighboring regions, and needs a separate VMA to represents each one.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I think ZGC<br>
could keep the number of VMAs down simply by processing mappings at<br>
larger granularity.<br>
<br>
There is a Fedora discussion under way to eliminate the kernel VMA limit<br>
completely, but the kernel OOM handler isn't really compatible with<br>
that.  The current heuristics do not seem to pick the most appropriate<br>
process if the kernel ends up with too much (unswappable?) memory used<br>
due to an excessive count of VMAs, so I'm not sure that we're going to<br>
change the default.<br>
<br>
  F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)<br>
  <<a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WVWHTLXSGZN4QMAE577ZFZX4ZI6YZF3A/" rel="noreferrer" target="_blank">https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WVWHTLXSGZN4QMAE577ZFZX4ZI6YZF3A/</a>><br>
<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Florian<br>
<br>
</blockquote></div></div>