RFR: 8324580: SIGFPE on THP initialization on kernels < 4.10 [v4]

[Stefan Johansson]

On Thu, 1 Feb 2024 10:32:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disable THP for too large page sizes
>
> MacOS error unrelated.
> @kstefanj could you take a look? This one is rather simple. Thanks!

Thanks for the ping @tstuefe =)

I think the approach to use the default large page size is good, but I think we should try to add the logic to `THPSupport::scan_os()` so it returns with a reasonable page size set. This will make the logging show the correct page size as well. If I'm not mistaken, right now the log will still render 0 as the THP page size:

[0.005s][info][pagesize] Transparent hugepage (THP) support:
[0.005s][info][pagesize]   THP mode: always
[0.005s][info][pagesize]   THP pagesize: 0B


If we update `THPSupport::scan_os()` to call `scan_default_hugepagesize()` if reading `hpage_pmd_size` fails we should be good. We can add a check there to limit the "default size" to 16M (which sounds reasonable) and maybe log that we did this limiting. I'm not certain what we should do if reading the default hugepage size fail (returns 0), but I'm leaning towards having 2M as a general fallback. It will only be used if THP mode is configured to `madvide` or `always` and in those cases we likely have at least a 2M page size (and I'm not sure this should ever happen). We could also add code to `validate_thps_configured()` to return false if the thp page size is 0.

An alternative to how we log this is to add a tag to the "THP pagesize" line, something like:

[0.005s][info][pagesize]   THP pagesize: 0B (configured/default/limited/fallback)

But I'm not sure how useful that is compared to have an additional log-line for the limited and fallback case.

If we go with this approach we should also update the testing code to do the same dance.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/17545#issuecomment-1926692575