Because pretouching involves writes, it must be done before any use of the memory. That can stall useful work that could be using some pages while the complete range gets touched.
An alternative to a simple store is an atomic add of zero to a location in the page. Performance testing suggests there isn't any noticeable difference between using ordinary stores and (relaxed) atomic add of zero to touch pages on either x64 or aarch64. The page allocation swamps the cost of the atomic operation.
- relates to
-
JDK-8283935 Parallel: Crash during pretouch after large pages allocation failure
- Resolved
-
JDK-8335865 Shenandoah: Improve THP pretouch after JDK-8315923
- Resolved
-
JDK-8338305 Linux kernels 5.8...5.13 are still affected by huge pages fragmentation even after JDK-8315923
- Open
-
JDK-8315923 pretouch_memory by atomic-add-0 fragments huge pages unexpectedly
- Resolved
- links to
-
Commit openjdk/jdk/072e7b4d
-
Review openjdk/jdk/5215
-
Review openjdk/jdk/5353
-
Review openjdk/jdk/7343