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

[Thomas Stuefe]

On Wed, 25 Oct 2023 07:42:23 GMT, Liming Liu <duke at openjdk.org> wrote:

>> 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.

Ah, ok, now I get it. You use the size to pick out the heap from the mappings. The problem here is that 1G is a really common size, and you may e.g. find the class space first, which is 1G in default size.

May I suggest two alternatives?


Alternative 1:

call the JVM with "-Xlog:pagesize". That will print out the heap location too, at least for G1, the default allocator:


thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -Xlog:pagesize                                   
...
[0.012s][info][pagesize] Heap:  min=8M max=16064M base=0x0000000414000000 size=16064M page_size=4K 


You can then parse the heap base from the output and use that to find the mapping.

Alternative 2:

Pass a really crooked size to -Xmx. Not as safe as alternative 1, but should work reasonably well.

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

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