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