From: Luiz Capitulino <luizcap@redhat.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
baolin.wang@linux.alibaba.com, ziy@nvidia.com,
lance.yang@linux.dev
Cc: 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, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, hughd@google.com,
dave.hansen@linux.intel.com, djbw@kernel.org,
vishal.l.verma@intel.com, dave.jiang@intel.com,
akpm@linux-foundation.org, yintirui@huawei.com, dev.jain@arm.com,
usama.arif@linux.dev
Subject: Re: [PATCH v8 09/14] powerpc: move has_transparent_hugepage() out of THP guard
Date: Sat, 3 Oct 2026 11:44:28 -0400 [thread overview]
Message-ID: <25bb02df-a795-4e48-9de6-99f1ca799176@redhat.com> (raw)
In-Reply-To: <f54d5d75-5cc1-488b-b640-76163419cf4d@kernel.org>
On 10/2/26 3:28 PM, David Hildenbrand (Arm) wrote:
> On 9/18/26 03:45, Luiz Capitulino wrote:
>> A future commit will introduce a kernel API to allow for checking if the
>> CPU supports PMD-sized pages. This API will be based on the
>> has_transparent_hugepage() implementation but will be orthogonal to THP
>> and therefore must work when CONFIG_TRANSPARENT_HUGEPAGE=n.
>>
>> Move its definition out of the THP guard.
>>
>> Signed-off-by: Luiz Capitulino <luizcap@redhat.com>
>> ---
>> arch/powerpc/include/asm/book3s/64/hash-4k.h | 2 +-
>> arch/powerpc/include/asm/book3s/64/hash-64k.h | 2 +-
>> arch/powerpc/include/asm/book3s/64/pgtable.h | 18 +++++++++---------
>> arch/powerpc/include/asm/book3s/64/radix.h | 14 +++++++-------
>> arch/powerpc/mm/book3s64/hash_pgtable.c | 4 ++--
>> 5 files changed, 20 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h b/arch/powerpc/include/asm/book3s/64/hash-4k.h
>> index 8e5bd9902bed..79511e6abfca 100644
>> --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
>> +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
>> @@ -165,9 +165,9 @@ extern void hash__pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
>> extern pgtable_t hash__pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp);
>> extern pmd_t hash__pmdp_huge_get_and_clear(struct mm_struct *mm,
>> unsigned long addr, pmd_t *pmdp);
>> -extern int hash__has_transparent_hugepage(void);
>> #endif
>>
>> +extern int hash__has_transparent_hugepage(void);
>> #endif /* !__ASSEMBLER__ */
>>
>> #endif /* _ASM_POWERPC_BOOK3S_64_HASH_4K_H */
>> diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> index 7deb3a66890b..a4a44a112ff9 100644
>> --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
>> @@ -278,9 +278,9 @@ extern void hash__pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
>> extern pgtable_t hash__pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp);
>> extern pmd_t hash__pmdp_huge_get_and_clear(struct mm_struct *mm,
>> unsigned long addr, pmd_t *pmdp);
>> -extern int hash__has_transparent_hugepage(void);
>
> Without some of these helpers in place, I assume actually using PMD leafs
> without THP would require some more work. (which is not the goal of this series,
> just asking).
Yes, you're right.
> I do wonder whether the architecture should instead simply say "not supported"
> if !CONFIG_TRANSPARENT_HUGEPAGE?
>
> That should still enable your series: using mTHP without PMD support.
Yes, it would. However, I think this introduces an inconsistency.
In in its current form, arch_has_pmd_leaves() should always report a hardware
capability. This is true even for the default case where
arch_has_pmd_leaves() defaults to
IS_ENABLED(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE) in the assumption that
archs supporting PMD-sized pages by default will have this config
enabled.
Your suggestion will change this and for some archs
arch_has_pmd_leaves() may have different behavior depending on the user
configuration. Additionally, I intended to decouple the base API
implementation from THP.
If you feel strongly about this I can implement your suggestion, but I'd
still vote for keeping the API about consistently reporting the hardware
capability. Even if the only user is THP code today, new use cases can
be added incrementally.
>
> [...]
>
>>
>> -static inline int radix__has_transparent_hugepage(void)
>> +static inline int radix__has_transparent_pud_hugepage(void)
>> {
>> - /* For radix 2M at PMD level means thp */
>> - if (mmu_psize_defs[MMU_PAGE_2M].shift == PMD_SHIFT)
>> + /* For radix 1G at PUD level means pud hugepage support */
>> + if (mmu_psize_defs[MMU_PAGE_1G].shift == PUD_SHIFT)
>> return 1;
>> return 0;
>> }
>> +#endif
>>
>> -static inline int radix__has_transparent_pud_hugepage(void)
>> +static inline int radix__has_transparent_hugepage(void)
>> {
>> - /* For radix 1G at PUD level means pud hugepage support */
>> - if (mmu_psize_defs[MMU_PAGE_1G].shift == PUD_SHIFT)
>> + /* For radix 2M at PMD level means thp */
>> + if (mmu_psize_defs[MMU_PAGE_2M].shift == PMD_SHIFT)
>> return 1;
>> return 0;
>> }
>
> You are swapping both implementations, which might create some unnecessary churn
> I think.
I suspect this was done by git diff as I just moved the functions, but
I'll take a better look.
next prev parent reply other threads:[~2026-10-03 15:44 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 1:45 [PATCH v8 00/14] mm: thp: always enable mTHP support Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 01/14] docs: tmpfs: remove implementation detail reference Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 02/14] mm: shmem: shmem_getattr(): set blksize to highest supported THP order Luiz Capitulino
2026-10-02 19:11 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 03/14] mm: introduce pgtable_has_pmd_leaves() Luiz Capitulino
2026-09-22 2:07 ` Zi Yan
2026-10-02 19:13 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 04/14] drivers: dax: use pgtable_has_pmd_leaves() Luiz Capitulino
2026-09-22 2:08 ` Zi Yan
2026-10-02 19:15 ` David Hildenbrand (Arm)
2026-10-03 14:55 ` Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 05/14] drivers: nvdimm: " Luiz Capitulino
2026-10-02 19:18 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 06/14] mm: debug_vm_pgtable: " Luiz Capitulino
2026-10-02 19:19 ` David Hildenbrand (Arm)
2026-10-03 14:55 ` Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 07/14] mm: shmem: allow THP support determination at folio allocation time Luiz Capitulino
2026-09-22 2:20 ` Zi Yan
2026-09-23 1:37 ` Luiz Capitulino
2026-10-02 19:23 ` David Hildenbrand (Arm)
2026-10-03 15:09 ` Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 08/14] s390: move has_transparent_hugepage() out of THP guard Luiz Capitulino
2026-09-22 2:21 ` Zi Yan
2026-10-02 19:24 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 09/14] powerpc: " Luiz Capitulino
2026-10-02 19:28 ` David Hildenbrand (Arm)
2026-10-03 15:44 ` Luiz Capitulino [this message]
2026-09-18 1:45 ` [PATCH v8 10/14] mips: " Luiz Capitulino
2026-10-02 19:29 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 11/14] x86: " Luiz Capitulino
2026-09-18 1:45 ` [PATCH v8 12/14] treewide: introduce arch_has_pmd_leaves() Luiz Capitulino
2026-09-22 2:26 ` Zi Yan
2026-09-18 1:45 ` [PATCH v8 13/14] mm: replace thp_disabled_by_hw() with pgtable_has_pmd_leaves() Luiz Capitulino
2026-10-02 19:32 ` David Hildenbrand (Arm)
2026-09-18 1:45 ` [PATCH v8 14/14] mm: thp: always enable mTHP support Luiz Capitulino
2026-09-18 9:01 ` Baolin Wang
2026-09-21 10:29 ` Usama Arif
2026-09-22 2:06 ` Luiz Capitulino
2026-10-03 3:13 ` Lance Yang
2026-10-03 15:50 ` Luiz Capitulino
2026-09-18 10:37 ` [PATCH v8 00/14] " Usama Arif
2026-09-18 14:01 ` Luiz Capitulino
2026-09-18 20:23 ` David Hildenbrand (Arm)
2026-09-21 10:36 ` Usama Arif
2026-09-22 2:11 ` 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=25bb02df-a795-4e48-9de6-99f1ca799176@redhat.com \
--to=luizcap@redhat.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=djbw@kernel.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hughd@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maddy@linux.ibm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=tglx@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=usama.arif@linux.dev \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
--cc=yintirui@huawei.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®