Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves()
From: Luiz Capitulino
Date: Wed May 13 2026 - 22:19:12 EST
On 2026-05-13 11:36, David Hildenbrand (Arm) wrote:
On 5/1/26 21:18, Luiz Capitulino wrote:
Currently, we have two helpers that check for PMD-sized pages but have
different names and slightly different semantics:
- has_transparent_hugepage(): the name suggests it checks if THP is
enabled, but when CONFIG_TRANSPARENT_HUGEPAGE=y and the architecture
implements this helper, it actually checks if the CPU supports
PMD-sized pages
- thp_disabled_by_hw(): the name suggests it checks if THP is disabled
by the hardware, but it just returns a cached value acquired with
has_transparent_hugepage(). This helper is used in fast paths
This commit introduces a new helper called pgtable_has_pmd_leaves()
which is intended to replace both has_transparent_hugepage() and
thp_disabled_by_hw(). pgtable_has_pmd_leaves() has very clear semantics:
it returns true if the CPU supports PMD-sized pages and false otherwise.
It always returns a cached value, so it can be used in fast paths.
Oh, one more thing: what will be the semantics regarding
CONFIG_TRANSPARENT_HUGEPAGE?
I assume it will only return true if CONFIG_TRANSPARENT_HUGEPAGE is enabled,
correct?
That is, for example, relevant for patch #2.
We could later change these semantics, but for now we should be very clear about
what it means.
I intended to decouple the API from CONFIG_TRANSPARENT_HUGEPAGE,so my
goal was to return true as long as PMD-sized pages are supported[*]. If
arch_has_pmd_leaves() is not implemented by the arch, we default to
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE, not CONFIG_TRANSPARENT_HUGEPAGE.
Now, do you mean to say that the API should still be tied to
CONFIG_TRANSPARENT_HUGEPAGE? If yes, why?
* Sashiko found out that the current arch_has_pmd_leaves()
implementation for x86 (and possibly the other archs) is guarded by
CONFIG_TRANSPARENT_HUGEPAGE, so we may return true without the
hardware check. But that's a bug