RFR: 8267155: runtime/os/TestTracePageSizes times out [v3]

[Aleksey Shipilev]

On Tue, 18 May 2021 06:40:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - heap size -> 128m
>>  - fixes
>
> Yes, I don't mind this going in. I was just pointing the way you could fix the test on <3.8 kernels either here on in separate PR.

> > Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR).
> 
> This test has been a bit of whack-a-mole; I am interested in a stable test which covers the important cases. E.g. I tried to find a clear definition of AnonHugePages but beyond that it requires the kernel to be compiled with THP I did not find any indication that this is synonymous with THP, or under which circumstances it is set, or whats its relationship to KernelPageSize is.

https://www.kernel.org/doc/Documentation/vm/transhuge.txt:
"The number of anonymous transparent huge pages currently used by the system is available by reading the AnonHugePages field in /proc/meminfo. To identify what applications are using anonymous transparent huge pages, it is necessary to read /proc/PID/smaps and count the AnonHugePages fields for each mapping."

But as we found earlier, this does not work because for many VM structures we are only _reserving_ the memory, while AnonHugePages > 0 only when we actually _commit_ stuff. So AnonHugePages is a lost cause, IMO. The only reliable way to test THP seems to be VmFlags. If VmFlags are not available, that the end. We can only stop testing for THP at that point...

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

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