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

[Stefan Johansson]

On Tue, 8 Dec 2020 08:49:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Hi Marcus,
>>> 
>>> I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes.
>>> 
>>> Cheers, Thomas
>> 
>> Hi Thomas. I was pushing to get this patch in before JDK16 was forked.
>> 
>> Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16?
>> 
>> As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs.
>
>> > Hi Marcus,
>> > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes.
>> > Cheers, Thomas
>> 
>> Hi Thomas. I was pushing to get this patch in before JDK16 was forked.
>> 
>> Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16?
>> 
>> As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs.
> 
> Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now.
> 
> Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good.
> 
> Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example:
> - we now have duplicate code for scanning the available huge pages
> - the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions.
> 
> I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16.
> 
> Cheers, Thomas

I will not be able to review this in time for the code freeze, so I also vote for not rushing it in.

Don't consider this a block, if you get other reviews I'm fine with it getting pushed.

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

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