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

[Luiz Capitulino]

On 2026-05-17 08:41, Lance Yang wrote:
> 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?

Yes, Sashiko caught this as well. I'll fix this for v5.

> > 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.

Agreed.