From: Lance Yang <lance.yang@linux.dev>
To: luizcap@redhat.com, david@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
baolin.wang@linux.alibaba.com, ziy@nvidia.com,
lance.yang@linux.dev, corbet@lwn.net, tsbogend@alpha.franken.de,
maddy@linux.ibm.com, mpe@ellerman.id.au, agordeev@linux.ibm.com,
gerald.schaefer@linux.ibm.com, hca@linux.ibm.com,
gor@linux.ibm.com, x86@kernel.org, dave.hansen@linux.intel.com,
djbw@kernel.org, vishal.l.verma@intel.com, dave.jiang@intel.com,
akpm@linux-foundation.org, lorenzo.stoakes@oracle.com
Subject: Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves()
Date: Sun, 17 May 2026 20:41:49 +0800 [thread overview]
Message-ID: <20260517124149.90033-1-lance.yang@linux.dev> (raw)
In-Reply-To: <1f4bccaf-6472-4e4c-92d0-28ac05f6f838@redhat.com>
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
next prev parent reply other threads:[~2026-05-17 12:42 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 19:18 [PATCH v4 0/9] mm: thp: always enable mTHP support Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 1/9] docs: tmpfs: remove implementation detail reference Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves() Luiz Capitulino
2026-05-06 17:50 ` (sashiko review) " Luiz Capitulino
2026-05-13 15:30 ` David Hildenbrand (Arm)
2026-05-14 1:52 ` Luiz Capitulino
2026-05-17 12:03 ` Lance Yang
2026-05-19 13:10 ` Luiz Capitulino
2026-05-13 15:36 ` David Hildenbrand (Arm)
2026-05-14 2:18 ` Luiz Capitulino
2026-05-17 12:41 ` Lance Yang [this message]
2026-05-19 13:14 ` Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 3/9] drivers: dax: use pgtable_has_pmd_leaves() Luiz Capitulino
2026-05-13 15:40 ` David Hildenbrand (Arm)
2026-05-14 2:25 ` Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 4/9] drivers: nvdimm: " Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 5/9] mm: debug_vm_pgtable: " Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 6/9] mm: shmem: drop has_transparent_hugepage() usage Luiz Capitulino
2026-05-06 18:12 ` (sashiko review) " Luiz Capitulino
2026-05-17 13:32 ` Lance Yang
2026-05-18 3:47 ` Baolin Wang
2026-05-18 5:00 ` Lance Yang
2026-05-01 19:18 ` [PATCH v4 7/9] treewide: introduce arch_has_pmd_leaves() Luiz Capitulino
2026-05-06 18:22 ` (sashiko review) " Luiz Capitulino
2026-05-06 18:30 ` Luiz Capitulino
2026-05-01 19:18 ` [PATCH v4 8/9] mm: replace thp_disabled_by_hw() with pgtable_has_pmd_leaves() Luiz Capitulino
2026-05-13 15:50 ` David Hildenbrand (Arm)
2026-05-01 19:18 ` [PATCH v4 9/9] mm: thp: always enable mTHP support Luiz Capitulino
2026-05-06 5:46 ` Baolin Wang
2026-05-06 18:34 ` (sashiko review) " Luiz Capitulino
2026-05-13 15:58 ` David Hildenbrand (Arm)
2026-05-14 1:14 ` Baolin Wang
2026-05-03 15:02 ` [PATCH v4 0/9] " Andrew Morton
2026-05-04 19:11 ` Luiz Capitulino
2026-05-14 6:35 ` Lorenzo Stoakes
2026-05-14 12:14 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260517124149.90033-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=luizcap@redhat.com \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=tsbogend@alpha.franken.de \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.