-
Bug
-
Resolution: Fixed
-
P4
-
22
-
b09
-
linux
When starting the JVM with -XX:+UseTransparentHugePages, we need to know if the OS supports THPs:
A) We could run on a super-old kernel (but THPs had been part of the kernel since 2.6.38, which is EOL since 2011, so we can assume all modern kernel can support THPs)
B) We could run on a kernel built without THP support, e.g. an embedded device
C) We could run on a system with THPs disabled by the admin
The JVM does a little sanity test at startup where it mmaps an area the size of a huge page - but in small pages - then calls madvise(MADV_HUGEPAGE) on it. The JVM assumes if the madvise() worked, all is a-ok.
That sanity test has little merit. It will weed out (A) and (B), but not (C) - it will always return success even if THPs are disabled on the system.
That sanity test is also expensive since we allocate (reserve AND commit) an area, then signal khugepaged by advising to fold it into a large page. That small-paged area is potentially large since there are plans to support 1 GB THP pages in the kernel, so we may end up allocating 1 GB space at startup for this sanity check.
The correct - and much cheaper - way is to check the proc fs whether THPs are enabled. We already do that sinceJDK-8310233: "Fix THP detection on Linux". That check takes care of (A)(B)(C). Therefore we can remove the THP sanity check completely.
A) We could run on a super-old kernel (but THPs had been part of the kernel since 2.6.38, which is EOL since 2011, so we can assume all modern kernel can support THPs)
B) We could run on a kernel built without THP support, e.g. an embedded device
C) We could run on a system with THPs disabled by the admin
The JVM does a little sanity test at startup where it mmaps an area the size of a huge page - but in small pages - then calls madvise(MADV_HUGEPAGE) on it. The JVM assumes if the madvise() worked, all is a-ok.
That sanity test has little merit. It will weed out (A) and (B), but not (C) - it will always return success even if THPs are disabled on the system.
That sanity test is also expensive since we allocate (reserve AND commit) an area, then signal khugepaged by advising to fold it into a large page. That small-paged area is potentially large since there are plans to support 1 GB THP pages in the kernel, so we may end up allocating 1 GB space at startup for this sanity check.
The correct - and much cheaper - way is to check the proc fs whether THPs are enabled. We already do that since
- relates to
-
JDK-8310262 Remove hugetlbfs sanity checks
-
- Open
-