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

[Marcus G K Williams]

On Wed, 14 Apr 2021 14:43:34 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> So now #3073 has been integrated, so you could merge with master to get this change.
> 

I will merge master and pickup change form #3073 today.

> I also discussed the meaning of `LargePageSizeInBytes` with some folks internally and @stefank pointed me to:
> https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html
> 
> There the flag is defined as:
> 
> ```
> -XX:LargePageSizeInBytes=size
>     Sets the maximum size (in bytes) for large pages used for the Java heap. The size argument must be
>     a power of 2 (2, 4, 8, 16, and so on). Append the letter k or K to indicate kilobytes, m or M to 
>     indicate megabytes, or g or G to indicate gigabytes. By default, the size is set to 0, meaning that 
>     the JVM chooses the size for large pages automatically. ...
> ```
> 
> So with this and what's in the code, the default behavior for the VM should be to try to use the best suitable large page size available for a mapping. If `LargePageSizeInBytes` is set this will limit the page sizes used to only include the ones less than or equal to `LargePageSizeInBytes`.
> 
> Does that make sense to everyone?

Thanks for the clarification @kstefanj. This makes sense and fits within my original goals for the change. What are your thoughts @tstuefe ?

> This will change the behavior compared to the what we have today:
> 
> * Default (`LargePageSizeInBytes=0`)
>   
>   * old behavior - use the systems default large page size
>   * new behavior - use all configure large page sizes
> * Value set (`LargePageSizeInBytes=X`)
>   
>   * old behavior - use only large pages of size X
>   * new behavior - use large pages of size X or smaller
>
> So the new behavior better fits what's in the docs, but I still suspect we might need a CSR.

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

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