RFR: 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available [v3]

[Stefan Johansson]

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ​to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ​
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

I would actually say this is adding new functionality. We have never had any fallback to smaller large page sizes if the configured one is not working properly. What we do have support for is to use smaller large page sizes for mappings that are smaller than the configured large page size. As we have discussed above, there is room for improvement in this area and I'm starting to think that moving towards something where `os::large_page_size()` is not even used should be the end goal. But as a first step, falling back to use smaller pages sizes is good.

To be more concrete about your patch, as I've said before, I would prefer a solution like the one I proposed above. Sure the heap might be aligned to something larger than what the final large page size require, but I don't think that's a very big issue since there will be quite few of these mappings (and again the user/administrator requested this alignment). Also, going with something like my suggestion above will cover more cases. For example, your proposed solution won't work if there is ONE 1G page available but not TWO. In this case the sanity check will pass, but your heap reservation will fail. 

I did spend some more time on my proposal to improve the logging and warnings a bit. Could probably be improved even further but you can take a look here to see the current state:
https://github.com/openjdk/jdk/compare/master...kstefanj:8271195-lp-fallback

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

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