RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v23]

[Stefan Johansson]

On Wed, 17 Mar 2021 14:55:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > This would also give us to to think about a question I haven't made up my mind around. What will `LargePageSizeInBytes` mean after this change? Should the JVM use 1g pages (on a system where 2m i the default) even if `LargePageSizeInBytes` is not set?
> 
> I see two valid scenarios:

Me too.

> a) either use huge pages as best as possible; remove fine-grained control from user hands. So, if we have 1G pages, prefer those over 2M over 4K. Then, we could completely remove LargePageSizeInBytes. There is no need for this switch anymore.

I agree, preferably we can make it so that the upper layers can use something like `page_size_for_region*` and request a certain page size, but fall back to smaller ones.

> b) or keep the current behavior. In that case, UseLargePageSize means "use at most default huge page size" even if larger pages are available; and LargePageSizeInBytes can be used to override the large page size to use.
> 

So it becomes more like a maximium value right? Or at least this is how I've thought about this second scenario. On a system with both 2M (the default size) and 1G pages available you would have to set `LargePageSizeInBytes=1g` to use the 1G pages, but the 2M could still be used for smaller mappings.

> (a): Its elegant, and efficiently uses system resources when available. But its an incompatible change, and the VM being grabby means we could end up using pages meant for a different process.
> (b): downward compatible. In a sense. With Marcus change, we break downward compatibility already: where "UseLargePageSizeInBytes" before meant "use that or nothing", it now means "use that or whatever smaller page sizes you find".
> 
> I prefer (a), honestly.
> 
I would also prefer (a).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1153