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

[Stefan Johansson]

On Tue, 16 Mar 2021 18:15:24 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

> 
> Hi Stefan ( @kstefanj ). Thanks for your review. I've addressed the specific suggestions.
> 
> > When deciding on a new page size we should honor the passed in alignment if it is larger than the allocation granularity. Because in such case the upper layer has made a decision that the lower layer should honor.
> 
> Also, I'm looking at this today, though not sure we can do this effectively without your refactoring.
> 
I agree, we need to have the alignment available when choosing page size for this to work.

> Thanks for pointing to JDK-8261527. I knew you were looking at large pages code and refactoring but I didn't know about JDK-8261527 or the other issues and PRs. I did run into the TestTracePageSizes.java while testing and saw some of the breadcrumbs. 👍
> 
> I would be a favor of using [master...kstefanj:8262291-one-special-alloc](https://github.com/openjdk/jdk/compare/master...kstefanj:8262291-one-special-alloc) as this looks like a good way forward. However, can we use my current PR as enabling of multiple page sizes and then later incorporate your refactoring?
> 
Depends on what you mean by enabling. I don't really see a way we can get to a point where we use multiple large page sizes without doing some refactoring. But if you by enable mean, that we just populate the page_size bitmap with all available large page sizes, I think this would be ok. We should rename the issue to reflect this in that case.

> > One other way forward (not waiting for refactoring) would be to see this change as just enabling use of multiple page sizes and then actually using them will be added later when needed refactoring has been done.
> 
> How would we go about doing your suggestion? There are two reasons I would like to get this PR in sooner rather than waiting, there is some pressure for me to put a bow on this change and I would really appreciate getting some changes in so that I can get my authorship in OpenJDK. I am happy to continue working on incremental changes to make page_size part of the code better and if I had a username I would suggest assigning some of the JDK-Issues to me. As an example I started looking at solving JDK-8263236, but couldn't comment or assign to myself.
> 
Totally understand that you want to get this in, I just want to make sure we make things fit together in a good way.

> Anyways, let me know how we can move forward and what the best path to get this change in for JDK-17.
>

I would prefer to split out the scanning part that add the large page sizes and then later on when everything else is in place, make use of this. This way we should be able to review this change pretty quickly and I can rebase my changes on yours. 

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? 

The current description for this flag is:
`"Large page size (0 to let VM choose the page size)")`

So we might need a CSR, depending on if the meaning of the flags changes. 

 
> Thanks,
> Marcus

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

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