From: Luiz Capitulino <luizcap@redhat.com>
To: Lance Yang <lance.yang@linux.dev>
Cc: corbet@lwn.net, ziy@nvidia.com, baolin.wang@linux.alibaba.com,
tsbogend@alpha.franken.de, maddy@linux.ibm.com,
mpe@ellerman.id.au, agordeev@linux.ibm.com,
gerald.schaefer@linux.ibm.com, david@kernel.org,
hca@linux.ibm.com, gor@linux.ibm.com, x86@kernel.org,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
hughd@google.com, linux-kernel@vger.kernel.org,
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, linux-mm@kvack.org
Subject: Re: [PATCH v7 10/14] mips: move has_transparent_hugepage() out of THP guard
Date: Tue, 1 Sep 2026 15:53:18 -0400 [thread overview]
Message-ID: <00eb76eb-c330-4662-9ca9-1e89fbc1e4ce@redhat.com> (raw)
In-Reply-To: <f4c568ad-a17a-4982-b8d2-d5852a789a4d@linux.dev>
On 2026-09-01 07:42, Lance Yang wrote:
>
>
> On 2026/9/1 11:12, 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/mips/include/asm/pgtable.h | 6 +++---
>> arch/mips/mm/tlb-r4k.c | 4 ----
>> 2 files changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
>> index fa7b935f947c..b038da872ec6 100644
>> --- a/arch/mips/include/asm/pgtable.h
>> +++ b/arch/mips/include/asm/pgtable.h
>> @@ -615,9 +615,6 @@ unsigned long io_remap_pfn_range_pfn(unsigned long pfn, unsigned long size);
>> /* We don't have hardware dirty/accessed bits, generic_pmdp_establish is fine.*/
>> #define pmdp_establish generic_pmdp_establish
>> -#define has_transparent_hugepage has_transparent_hugepage
>> -extern int has_transparent_hugepage(void);
>
> Assume a decstation_defconfig build. CPU_R3000 selects CPU_R3K_TLB, so the
> Makefile builds tlb-r3k.o but not tlb-r4k.o IIUC ...
>
> The only MIPS definition is in tlb-r4k.c, so R3000 would fail to link with
> an undefined reference ... no?
Yes, you're right. I can reproduce this. Would the solution below be
acceptable?
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index fa7b935f947c..b038da872ec6 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -615,9 +615,6 @@ unsigned long io_remap_pfn_range_pfn(unsigned long pfn, unsigned long size);
/* We don't have hardware dirty/accessed bits, generic_pmdp_establish is fine.*/
#define pmdp_establish generic_pmdp_establish
-#define has_transparent_hugepage has_transparent_hugepage
-extern int has_transparent_hugepage(void);
-
static inline int pmd_trans_huge(pmd_t pmd)
{
return !!(pmd_val(pmd) & _PAGE_HUGE);
@@ -743,6 +740,9 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#define has_transparent_hugepage has_transparent_hugepage
+extern int has_transparent_hugepage(void);
+
#ifdef _PAGE_HUGE
#define pmd_leaf(pmd) ((pmd_val(pmd) & _PAGE_HUGE) != 0)
#define pud_leaf(pud) ((pud_val(pud) & _PAGE_HUGE) != 0)
diff --git a/arch/mips/mm/pgtable.c b/arch/mips/mm/pgtable.c
index 10835414819f..3a5b411493d9 100644
--- a/arch/mips/mm/pgtable.c
+++ b/arch/mips/mm/pgtable.c
@@ -23,3 +23,30 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
return ret;
}
EXPORT_SYMBOL_GPL(pgd_alloc);
+
+#if defined(CONFIG_CPU_R4K_CACHE_TLB) || \
+ defined(CONFIG_CPU_SB1) || \
+ defined(CONFIG_CPU_CAVIUM_OCTEON)
+int has_transparent_hugepage(void)
+{
+ static unsigned int mask = -1;
+
+ if (mask == -1) { /* first call comes during __init */
+ unsigned long flags;
+
+ local_irq_save(flags);
+ write_c0_pagemask(PM_HUGE_MASK);
+ back_to_back_c0_hazard();
+ mask = read_c0_pagemask();
+ write_c0_pagemask(PM_DEFAULT_MASK);
+ local_irq_restore(flags);
+ }
+ return mask == PM_HUGE_MASK;
+}
+#else
+int has_transparent_hugepage(void)
+{
+ return 0;
+}
+#endif
+EXPORT_SYMBOL(has_transparent_hugepage);
diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index 24fe85fa169d..625f1c0dd71e 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -432,28 +432,6 @@ void add_wired_entry(unsigned long entrylo0, unsigned long entrylo1,
#endif
}
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-
-int has_transparent_hugepage(void)
-{
- static unsigned int mask = -1;
-
- if (mask == -1) { /* first call comes during __init */
- unsigned long flags;
-
- local_irq_save(flags);
- write_c0_pagemask(PM_HUGE_MASK);
- back_to_back_c0_hazard();
- mask = read_c0_pagemask();
- write_c0_pagemask(PM_DEFAULT_MASK);
- local_irq_restore(flags);
- }
- return mask == PM_HUGE_MASK;
-}
-EXPORT_SYMBOL(has_transparent_hugepage);
-
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-
/*
* Used for loading TLB entries before trap_init() has started, when we
* don't actually want to add a wired entry which remains throughout the
--
2.55.0
next prev parent reply other threads:[~2026-09-01 19:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 3:12 [PATCH v7 00/14] mm: thp: always enable mTHP support Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 01/14] docs: tmpfs: remove implementation detail reference Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 02/14] mm: shmem: shmem_getattr(): set blksize to highest supported THP order Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 03/14] mm: introduce pgtable_has_pmd_leaves() Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 04/14] drivers: dax: use pgtable_has_pmd_leaves() Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 05/14] drivers: nvdimm: " Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 06/14] mm: debug_vm_pgtable: " Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 07/14] mm: shmem: allow THP support determination at folio allocation time Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 08/14] s390: move has_transparent_hugepage() out of THP guard Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 09/14] powerpc: " Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 10/14] mips: " Luiz Capitulino
2026-09-01 11:42 ` Lance Yang
2026-09-01 19:53 ` Luiz Capitulino [this message]
2026-09-01 22:25 ` Thomas Bogendoerfer
2026-09-02 15:12 ` Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 11/14] x86: " Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 12/14] treewide: introduce arch_has_pmd_leaves() Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 13/14] mm: replace thp_disabled_by_hw() with pgtable_has_pmd_leaves() Luiz Capitulino
2026-09-01 3:12 ` [PATCH v7 14/14] mm: thp: always enable mTHP support 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=00eb76eb-c330-4662-9ca9-1e89fbc1e4ce@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 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.