RFR: 8315923: pretouch_memory by atomic-add-0 fragments huge pages unexpectedly [v21]
Thomas Stuefe
stuefe at openjdk.org
Fri Jan 12 09:53:29 UTC 2024
On Fri, 12 Jan 2024 06:30:03 GMT, Liming Liu <duke at openjdk.org> wrote:
>> src/hotspot/share/runtime/os.cpp line 2125:
>>
>>> 2123: for (char* cur = static_cast<char*>(first); /* break */; cur += page_size) {
>>> 2124: Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
>>> 2125: if (cur >= last) break;
>>
>> I suggest a slightly different flow, similar to how we do things in other areas:
>>
>> os.hpp
>>
>>
>> private:
>> bool pd_pretouch_memory(..);
>> public:
>> void pretouch_memory(..);
>>
>>
>> os.cpp
>>
>> void os::pretouch_memory(..) {
>> // Ask platform first
>> if (pd_pretouch_memory(..)) {
>> return;
>> }
>> ... do pretouching by touching
>> }
>>
>>
>> then provide a pd_pretouch for every platform; let other platforms be just a noop returning false, on Linux - if THPs are enabled and so forth, do the madvise and return true.
>>
>> One function less in the os namespace, and we don't call back from a pd_... function into a generic function which is unusual.
>
> Linux requires a different page size for touching when THP is enabled. Should I change page_size to a reference or let pd_pretouch_memory return the page size for touching rather than a false?
Oh, you are right. Yes, that makes sense, return the pagesize as "touching pagesize overrides huge page size". Alternatively, return a boolean that says "touch with system page size, not with the assumed large page size".
Up to you. Also up to you if you do this as a separate return value (as in `bool os::pd_pretouch_memory(.., .., bool& use_system_page_size);` or whether you do this via return value, e.g. as in "returns 0 if pretouching was done, >0 if not done, in which case its the page size to use". (While writing this, I feel that a separate parameter is cleaner, but up to you).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15781#discussion_r1450153626
More information about the hotspot-runtime-dev
mailing list