Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves()

[Lance Yang]

On Wed, May 13, 2026 at 10:18:48PM -0400, Luiz Capitulino wrote:
>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.

After patch #07, what still confuses me a bit is that the arch hoooks for
arch_has_pmd_leaves() still seems to be guarded by
CONFIG_TRANSPARENT_HUGEPAGE, not CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE ..

For example, x86 only define arch_has_pmd_leaves() when
CONFIG_TRANSPARENT_HUGEPAGE=y, Same for s390 and mips, unless I missed
something.

So is the intended meaning:

"this arch can support PMD leaves"

or

"this CPU actually supports PMD leaves"

?

If it's the second one, shouldn't the arch_has_pmd_leaves hooks move
out of the CONFIG_TRANSPARENT_HUGEPAGE guards as well?

>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

Not sure whether that bug can actually happen ...

But decoupling them looks cleaner to me :)

CONFIG_TRANSPARENT_HUGEPAGE controls whether THP code is built, while
arch_has_pmd_leaves() is about PMD-leaf capability.

Cheers, Lance