Kernel series keeps mTHP on when PMD huge pages are missing

Luiz Capitulino has sent a memory-management series that keeps multi-size transparent huge pages (mTHP) usable even when the CPU cannot map traditional PMD-sized huge pages.

The root issue was an overloaded helper. Architectures that supply has_transparent_hugepage() used it both as a stand-in for “THP is built in” and as a probe for PMD-sized page support. Core THP and shmem code then switched heavily on that result. On hardware without PMD leaves, every THP size was turned off, including smaller mTHP orders, and the transparent_hugepage sysfs interface disappeared entirely. Machines that never had PMD-sized pages therefore lost mTHP for no good reason.

The series splits those checks. Whether THP exists is answered with the CONFIG_TRANSPARENT_HUGEPAGE build option. A new helper, pgtable_has_pmd_leaves(), reports only whether the CPU supports PMD-sized mappings; it is cached via a static key and safe on fast paths. Core THP and shmem still filter out PMD (and PUD) orders at page-fault or folio-allocation time when those leaves are absent, but other mTHP sizes stay enabled. On CPUs that do support PMD leaves, behavior is unchanged.

Call sites in DAX alignment, NVDIMM PFN devices, debug page-table tests, and shmem were converted to the clearer split. Architecture probes on s390, powerpc, MIPS, and x86 were moved out of the THP config guard and renamed to match the new PMD-leaf meaning. After the change, /sys/kernel/mm/transparent_hugepage and hpage_pmd_size remain present; only the hugepages entry for an unsupported PMD size is omitted. Shmem getattr also reports blksize from the highest actually supported order rather than always assuming PMD size.

David Hildenbrand suggested the direction. The practical effect is that mTHP is no longer held hostage to PMD-sized page support on arches and CPUs that never offered it.