RFR: 8315923: pretouch_memory by atomic-add-0 fragments huge pages unexpectedly [v7]

[Liming Liu]

On Tue, 24 Oct 2023 13:49:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Liming Liu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Make the jtreg test check the usage of THP
>
> test/hotspot/jtreg/runtime/os/TestTransparentHugePageUsage.java line 37:
> 
>> 35:  *                   -Xms24G -Xmx24G -XX:+AlwaysPreTouch
>> 36:  *                   runtime.os.TestTransparentHugePageUsage
>> 37:  */
> 
> Requiring the test to need 24G is a lot... why does it need to be so large?
> 
> What does the test test? The problem was that pre-touching the memory would allocate small pages, and then later khugepaged would fold them into large pages at its own leisure. Your patch prevents that, so now huge pages form faster? So, the success of the patch can be described by timing?

I changed the size to 1G which means two thp on aarch64 with 64KB page sizes. The test now checks the usage of thp, and will fail when the policy is madvise and the method of pretouch is atomic-add on aarch64. Timing is a factor, but have to be checked manually from the log, as there is no standard on how fast it should be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15781#discussion_r1371292758