From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
Russell King <linux@armlinux.org.uk>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>, Anup Patel <anup@brainfault.org>,
Atish Patra <atish.patra@linux.dev>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-openrisc@vger.kernel.org
Subject: Re: [PATCH RFC v3 15/21] x86: mm: skip collapse_pud_page() when CONFIG_X86_DIRECT_GBPAGES disabled
Date: Wed, 2 Sep 2026 17:48:14 +0100 [thread overview]
Message-ID: <aphTTqhf3yO74JoO@e129823.arm.com> (raw)
In-Reply-To: <fa4acc56-9742-4a5e-abd4-7491ad426940@intel.com>
Hi Dave,
> On 9/2/26 04:56, Yeoreum Yun wrote:
> > The behaviour of pXd_page() will change with generic compile-time folded
> > page tables by disallowing its use and triggering a compile-time error
> > when it's used improperly, ensuring that the actual pXd_page() is used
> > instead.
> >
> > To prepare fot that, skip collapse_pud_page() when
> > CONFIG_X86_DIRECT_GBPAGES is disabled.
>
> Nit: this doesn't explain how the change actually fixes anything or what
> the specific problem being solved is.
>
> I think you want to say something along the lines of:
>
> collapse_pud_page() uses pud_page() in a way which will soon
> trigger a compile-time error on configs that have a folded pud.
>
> The code which will generate that error is actually unreachable
> on those configs because 'direct_gbpages' is always 0 there.
> However, the compiler does not know that because
> 'direct_gbpages' is a normal integer from a separate compilation
> unit.
>
> Make the compiler aware when most of collapse_pud_page() is
> unreachable by adding a Kconfig check. This ensures it will not
> trip the errors when they are introduced. It probably also trims
> the kernel image down a wee bit too as a side benefit.
Yes.. Sorry for my poor commit message.
>
> Maybe I should just merge something like the attached patch. I think it
> would solve your problem and make things generally cleaner too.
>
> There is an existing variable (direct_gbpages) that says whether the
> kernel can and should use 1G pages in the direct map. It is driven
> by a bunch of other machinery. At least:
>
> 1. Hardware support for 1G pages
> 2. Kconfig support for 1G direct mappings
> 3. Kernel command line overrides
>
> Most code just checks the 'direct_gbpages' variable itself. But this
> prevents compiler optimization in cases where 1G mappings are
> compile-time disabled (via X86_DIRECT_GBPAGES).
>
> Add a helper to replace 'direct_gbpages' checks. Check the Kconfig
> option and base CPU support before looking at the variable.
>
> This lets the compiler optimize things better, especially
> collapse_pud_page() where most of the function can now be optimized
> away.
Yeap. I've tested with your patch and it works for me!
Thanks!
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Tested-by: Yeoreum Yun <yeoreum.yun@arm.com>
>
> ---
>
> b/arch/x86/include/asm/pgtable.h | 14 ++++++++++++++
> b/arch/x86/kernel/cpu/common.c | 2 +-
> b/arch/x86/kernel/machine_kexec_64.c | 2 +-
> b/arch/x86/mm/init.c | 2 +-
> b/arch/x86/mm/pat/set_memory.c | 4 ++--
> 5 files changed, 19 insertions(+), 5 deletions(-)
>
> diff -puN arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime 2026-09-02 06:53:57.835733398 -0700
> +++ b/arch/x86/include/asm/pgtable.h 2026-09-02 08:17:01.434727771 -0700
> @@ -1163,6 +1163,20 @@ static inline int pgd_none(pgd_t pgd)
> #ifndef __ASSEMBLER__
>
> extern int direct_gbpages;
> +static inline bool direct_gbpages_enabled(void)
> +{
> + /* Check the direct map config option: */
> + if (!IS_ENABLED(CONFIG_X86_DIRECT_GBPAGES))
> + return false;
> +
> + /* Check the CPU feature: */
> + if (!cpu_feature_enabled(X86_FEATURE_GBPAGES))
> + return false;
> +
> + /* Check the command-line and early setup variable: */
> + return direct_gbpages;
> +}
> +
> void init_mem_mapping(void);
> void early_alloc_pgt_buf(void);
> void __init poking_init(void);
> diff -puN arch/x86/mm/init.c~direct_gbpages-compiletime arch/x86/mm/init.c
> --- a/arch/x86/mm/init.c~direct_gbpages-compiletime 2026-09-02 06:55:01.004094924 -0700
> +++ b/arch/x86/mm/init.c 2026-09-02 08:20:36.759992562 -0700
> @@ -251,7 +251,7 @@ static void __init probe_page_size_mask(
> __default_kernel_pte_mask &= ~_PAGE_GLOBAL;
>
> /* Enable 1 GB linear kernel mappings if available: */
> - if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
> + if (direct_gbpages_enabled()) {
> printk(KERN_INFO "Using GB pages for direct mapping\n");
> page_size_mask |= 1 << PG_LEVEL_1G;
> } else {
> diff -puN arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime arch/x86/kernel/cpu/common.c
> --- a/arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime 2026-09-02 06:57:47.935849397 -0700
> +++ b/arch/x86/kernel/cpu/common.c 2026-09-02 06:57:57.299617535 -0700
> @@ -2660,7 +2660,7 @@ void __init arch_cpu_finalize_init(void)
> * Right now we don't do that with gbpages because there seems
> * very little benefit for that case.
> */
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> set_memory_4k((unsigned long)__va(0), 1);
> } else {
> fpu__init_check_bugs();
> diff -puN arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime arch/x86/kernel/machine_kexec_64.c
> --- a/arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime 2026-09-02 06:57:58.462712975 -0700
> +++ b/arch/x86/kernel/machine_kexec_64.c 2026-09-02 06:58:05.219267514 -0700
> @@ -257,7 +257,7 @@ static int init_pgtable(struct kimage *i
> info.kernpg_flag |= _PAGE_ENC;
> }
>
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> info.direct_gbpages = true;
>
> for (i = 0; i < nr_pfn_mapped; i++) {
> diff -puN arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime arch/x86/mm/pat/set_memory.c
> --- a/arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime 2026-09-02 06:58:43.518414555 -0700
> +++ b/arch/x86/mm/pat/set_memory.c 2026-09-02 06:59:27.252015369 -0700
> @@ -130,7 +130,7 @@ void arch_report_meminfo(struct seq_file
> seq_printf(m, "DirectMap4M: %8lu kB\n",
> direct_pages_count[PG_LEVEL_2M] << 12);
> #endif
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> seq_printf(m, "DirectMap1G: %8lu kB\n",
> direct_pages_count[PG_LEVEL_1G] << 20);
> }
> @@ -1340,7 +1340,7 @@ static int collapse_pud_page(pud_t *pud,
> pmd_t *pmd, first;
> int i;
>
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> return 0;
>
> addr &= PUD_MASK;
> _
--
Sincerely,
Yeoreum Yun
WARNING: multiple messages have this Message-ID (diff)
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
Russell King <linux@armlinux.org.uk>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>, Anup Patel <anup@brainfault.org>,
Atish Patra <atish.patra@linux.dev>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-openrisc@vger.kernel.org
Subject: Re: [PATCH RFC v3 15/21] x86: mm: skip collapse_pud_page() when CONFIG_X86_DIRECT_GBPAGES disabled
Date: Wed, 2 Sep 2026 17:48:14 +0100 [thread overview]
Message-ID: <aphTTqhf3yO74JoO@e129823.arm.com> (raw)
In-Reply-To: <fa4acc56-9742-4a5e-abd4-7491ad426940@intel.com>
Hi Dave,
> On 9/2/26 04:56, Yeoreum Yun wrote:
> > The behaviour of pXd_page() will change with generic compile-time folded
> > page tables by disallowing its use and triggering a compile-time error
> > when it's used improperly, ensuring that the actual pXd_page() is used
> > instead.
> >
> > To prepare fot that, skip collapse_pud_page() when
> > CONFIG_X86_DIRECT_GBPAGES is disabled.
>
> Nit: this doesn't explain how the change actually fixes anything or what
> the specific problem being solved is.
>
> I think you want to say something along the lines of:
>
> collapse_pud_page() uses pud_page() in a way which will soon
> trigger a compile-time error on configs that have a folded pud.
>
> The code which will generate that error is actually unreachable
> on those configs because 'direct_gbpages' is always 0 there.
> However, the compiler does not know that because
> 'direct_gbpages' is a normal integer from a separate compilation
> unit.
>
> Make the compiler aware when most of collapse_pud_page() is
> unreachable by adding a Kconfig check. This ensures it will not
> trip the errors when they are introduced. It probably also trims
> the kernel image down a wee bit too as a side benefit.
Yes.. Sorry for my poor commit message.
>
> Maybe I should just merge something like the attached patch. I think it
> would solve your problem and make things generally cleaner too.
>
> There is an existing variable (direct_gbpages) that says whether the
> kernel can and should use 1G pages in the direct map. It is driven
> by a bunch of other machinery. At least:
>
> 1. Hardware support for 1G pages
> 2. Kconfig support for 1G direct mappings
> 3. Kernel command line overrides
>
> Most code just checks the 'direct_gbpages' variable itself. But this
> prevents compiler optimization in cases where 1G mappings are
> compile-time disabled (via X86_DIRECT_GBPAGES).
>
> Add a helper to replace 'direct_gbpages' checks. Check the Kconfig
> option and base CPU support before looking at the variable.
>
> This lets the compiler optimize things better, especially
> collapse_pud_page() where most of the function can now be optimized
> away.
Yeap. I've tested with your patch and it works for me!
Thanks!
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Tested-by: Yeoreum Yun <yeoreum.yun@arm.com>
>
> ---
>
> b/arch/x86/include/asm/pgtable.h | 14 ++++++++++++++
> b/arch/x86/kernel/cpu/common.c | 2 +-
> b/arch/x86/kernel/machine_kexec_64.c | 2 +-
> b/arch/x86/mm/init.c | 2 +-
> b/arch/x86/mm/pat/set_memory.c | 4 ++--
> 5 files changed, 19 insertions(+), 5 deletions(-)
>
> diff -puN arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime 2026-09-02 06:53:57.835733398 -0700
> +++ b/arch/x86/include/asm/pgtable.h 2026-09-02 08:17:01.434727771 -0700
> @@ -1163,6 +1163,20 @@ static inline int pgd_none(pgd_t pgd)
> #ifndef __ASSEMBLER__
>
> extern int direct_gbpages;
> +static inline bool direct_gbpages_enabled(void)
> +{
> + /* Check the direct map config option: */
> + if (!IS_ENABLED(CONFIG_X86_DIRECT_GBPAGES))
> + return false;
> +
> + /* Check the CPU feature: */
> + if (!cpu_feature_enabled(X86_FEATURE_GBPAGES))
> + return false;
> +
> + /* Check the command-line and early setup variable: */
> + return direct_gbpages;
> +}
> +
> void init_mem_mapping(void);
> void early_alloc_pgt_buf(void);
> void __init poking_init(void);
> diff -puN arch/x86/mm/init.c~direct_gbpages-compiletime arch/x86/mm/init.c
> --- a/arch/x86/mm/init.c~direct_gbpages-compiletime 2026-09-02 06:55:01.004094924 -0700
> +++ b/arch/x86/mm/init.c 2026-09-02 08:20:36.759992562 -0700
> @@ -251,7 +251,7 @@ static void __init probe_page_size_mask(
> __default_kernel_pte_mask &= ~_PAGE_GLOBAL;
>
> /* Enable 1 GB linear kernel mappings if available: */
> - if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
> + if (direct_gbpages_enabled()) {
> printk(KERN_INFO "Using GB pages for direct mapping\n");
> page_size_mask |= 1 << PG_LEVEL_1G;
> } else {
> diff -puN arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime arch/x86/kernel/cpu/common.c
> --- a/arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime 2026-09-02 06:57:47.935849397 -0700
> +++ b/arch/x86/kernel/cpu/common.c 2026-09-02 06:57:57.299617535 -0700
> @@ -2660,7 +2660,7 @@ void __init arch_cpu_finalize_init(void)
> * Right now we don't do that with gbpages because there seems
> * very little benefit for that case.
> */
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> set_memory_4k((unsigned long)__va(0), 1);
> } else {
> fpu__init_check_bugs();
> diff -puN arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime arch/x86/kernel/machine_kexec_64.c
> --- a/arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime 2026-09-02 06:57:58.462712975 -0700
> +++ b/arch/x86/kernel/machine_kexec_64.c 2026-09-02 06:58:05.219267514 -0700
> @@ -257,7 +257,7 @@ static int init_pgtable(struct kimage *i
> info.kernpg_flag |= _PAGE_ENC;
> }
>
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> info.direct_gbpages = true;
>
> for (i = 0; i < nr_pfn_mapped; i++) {
> diff -puN arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime arch/x86/mm/pat/set_memory.c
> --- a/arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime 2026-09-02 06:58:43.518414555 -0700
> +++ b/arch/x86/mm/pat/set_memory.c 2026-09-02 06:59:27.252015369 -0700
> @@ -130,7 +130,7 @@ void arch_report_meminfo(struct seq_file
> seq_printf(m, "DirectMap4M: %8lu kB\n",
> direct_pages_count[PG_LEVEL_2M] << 12);
> #endif
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> seq_printf(m, "DirectMap1G: %8lu kB\n",
> direct_pages_count[PG_LEVEL_1G] << 20);
> }
> @@ -1340,7 +1340,7 @@ static int collapse_pud_page(pud_t *pud,
> pmd_t *pmd, first;
> int i;
>
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> return 0;
>
> addr &= PUD_MASK;
> _
--
Sincerely,
Yeoreum Yun
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
Russell King <linux@armlinux.org.uk>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>, Anup Patel <anup@brainfault.org>,
Atish Patra <atish.patra@linux.dev>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-openrisc@vger.kernel.org
Subject: Re: [PATCH RFC v3 15/21] x86: mm: skip collapse_pud_page() when CONFIG_X86_DIRECT_GBPAGES disabled
Date: Wed, 2 Sep 2026 17:48:14 +0100 [thread overview]
Message-ID: <aphTTqhf3yO74JoO@e129823.arm.com> (raw)
In-Reply-To: <fa4acc56-9742-4a5e-abd4-7491ad426940@intel.com>
Hi Dave,
> On 9/2/26 04:56, Yeoreum Yun wrote:
> > The behaviour of pXd_page() will change with generic compile-time folded
> > page tables by disallowing its use and triggering a compile-time error
> > when it's used improperly, ensuring that the actual pXd_page() is used
> > instead.
> >
> > To prepare fot that, skip collapse_pud_page() when
> > CONFIG_X86_DIRECT_GBPAGES is disabled.
>
> Nit: this doesn't explain how the change actually fixes anything or what
> the specific problem being solved is.
>
> I think you want to say something along the lines of:
>
> collapse_pud_page() uses pud_page() in a way which will soon
> trigger a compile-time error on configs that have a folded pud.
>
> The code which will generate that error is actually unreachable
> on those configs because 'direct_gbpages' is always 0 there.
> However, the compiler does not know that because
> 'direct_gbpages' is a normal integer from a separate compilation
> unit.
>
> Make the compiler aware when most of collapse_pud_page() is
> unreachable by adding a Kconfig check. This ensures it will not
> trip the errors when they are introduced. It probably also trims
> the kernel image down a wee bit too as a side benefit.
Yes.. Sorry for my poor commit message.
>
> Maybe I should just merge something like the attached patch. I think it
> would solve your problem and make things generally cleaner too.
>
> There is an existing variable (direct_gbpages) that says whether the
> kernel can and should use 1G pages in the direct map. It is driven
> by a bunch of other machinery. At least:
>
> 1. Hardware support for 1G pages
> 2. Kconfig support for 1G direct mappings
> 3. Kernel command line overrides
>
> Most code just checks the 'direct_gbpages' variable itself. But this
> prevents compiler optimization in cases where 1G mappings are
> compile-time disabled (via X86_DIRECT_GBPAGES).
>
> Add a helper to replace 'direct_gbpages' checks. Check the Kconfig
> option and base CPU support before looking at the variable.
>
> This lets the compiler optimize things better, especially
> collapse_pud_page() where most of the function can now be optimized
> away.
Yeap. I've tested with your patch and it works for me!
Thanks!
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Tested-by: Yeoreum Yun <yeoreum.yun@arm.com>
>
> ---
>
> b/arch/x86/include/asm/pgtable.h | 14 ++++++++++++++
> b/arch/x86/kernel/cpu/common.c | 2 +-
> b/arch/x86/kernel/machine_kexec_64.c | 2 +-
> b/arch/x86/mm/init.c | 2 +-
> b/arch/x86/mm/pat/set_memory.c | 4 ++--
> 5 files changed, 19 insertions(+), 5 deletions(-)
>
> diff -puN arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~direct_gbpages-compiletime 2026-09-02 06:53:57.835733398 -0700
> +++ b/arch/x86/include/asm/pgtable.h 2026-09-02 08:17:01.434727771 -0700
> @@ -1163,6 +1163,20 @@ static inline int pgd_none(pgd_t pgd)
> #ifndef __ASSEMBLER__
>
> extern int direct_gbpages;
> +static inline bool direct_gbpages_enabled(void)
> +{
> + /* Check the direct map config option: */
> + if (!IS_ENABLED(CONFIG_X86_DIRECT_GBPAGES))
> + return false;
> +
> + /* Check the CPU feature: */
> + if (!cpu_feature_enabled(X86_FEATURE_GBPAGES))
> + return false;
> +
> + /* Check the command-line and early setup variable: */
> + return direct_gbpages;
> +}
> +
> void init_mem_mapping(void);
> void early_alloc_pgt_buf(void);
> void __init poking_init(void);
> diff -puN arch/x86/mm/init.c~direct_gbpages-compiletime arch/x86/mm/init.c
> --- a/arch/x86/mm/init.c~direct_gbpages-compiletime 2026-09-02 06:55:01.004094924 -0700
> +++ b/arch/x86/mm/init.c 2026-09-02 08:20:36.759992562 -0700
> @@ -251,7 +251,7 @@ static void __init probe_page_size_mask(
> __default_kernel_pte_mask &= ~_PAGE_GLOBAL;
>
> /* Enable 1 GB linear kernel mappings if available: */
> - if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
> + if (direct_gbpages_enabled()) {
> printk(KERN_INFO "Using GB pages for direct mapping\n");
> page_size_mask |= 1 << PG_LEVEL_1G;
> } else {
> diff -puN arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime arch/x86/kernel/cpu/common.c
> --- a/arch/x86/kernel/cpu/common.c~direct_gbpages-compiletime 2026-09-02 06:57:47.935849397 -0700
> +++ b/arch/x86/kernel/cpu/common.c 2026-09-02 06:57:57.299617535 -0700
> @@ -2660,7 +2660,7 @@ void __init arch_cpu_finalize_init(void)
> * Right now we don't do that with gbpages because there seems
> * very little benefit for that case.
> */
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> set_memory_4k((unsigned long)__va(0), 1);
> } else {
> fpu__init_check_bugs();
> diff -puN arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime arch/x86/kernel/machine_kexec_64.c
> --- a/arch/x86/kernel/machine_kexec_64.c~direct_gbpages-compiletime 2026-09-02 06:57:58.462712975 -0700
> +++ b/arch/x86/kernel/machine_kexec_64.c 2026-09-02 06:58:05.219267514 -0700
> @@ -257,7 +257,7 @@ static int init_pgtable(struct kimage *i
> info.kernpg_flag |= _PAGE_ENC;
> }
>
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> info.direct_gbpages = true;
>
> for (i = 0; i < nr_pfn_mapped; i++) {
> diff -puN arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime arch/x86/mm/pat/set_memory.c
> --- a/arch/x86/mm/pat/set_memory.c~direct_gbpages-compiletime 2026-09-02 06:58:43.518414555 -0700
> +++ b/arch/x86/mm/pat/set_memory.c 2026-09-02 06:59:27.252015369 -0700
> @@ -130,7 +130,7 @@ void arch_report_meminfo(struct seq_file
> seq_printf(m, "DirectMap4M: %8lu kB\n",
> direct_pages_count[PG_LEVEL_2M] << 12);
> #endif
> - if (direct_gbpages)
> + if (direct_gbpages_enabled())
> seq_printf(m, "DirectMap1G: %8lu kB\n",
> direct_pages_count[PG_LEVEL_1G] << 20);
> }
> @@ -1340,7 +1340,7 @@ static int collapse_pud_page(pud_t *pud,
> pmd_t *pmd, first;
> int i;
>
> - if (!direct_gbpages)
> + if (!direct_gbpages_enabled())
> return 0;
>
> addr &= PUD_MASK;
> _
--
Sincerely,
Yeoreum Yun
--
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv
next prev parent reply other threads:[~2026-09-02 16:48 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 11:56 [PATCH RFC v3 00/21] mm: change behavior of pXdp_get()/pXd_page() in compile-time folded pgtable Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 01/21] ARM: mm: make nommu pgd_t a scalar Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 02/21] ARM: mm: make 2-level " Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 03/21] ARM: mm: remove custom pgdp_get() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 04/21] LoongArch: mm: define pud_leaf() only when PUD exists Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 05/21] MIPS: " Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 06/21] mm/pgtable: define (pgd|p4d|pud)_leaf() for folded page tables Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 12:15 ` sashiko-bot
2026-09-02 11:56 ` [PATCH RFC v3 07/21] mm/pgtable: define (pgd|p4d|pud)_offset_lockless() " Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 08/21] mm: vmscan: remove stack copy address of pud/pmd pass in walk_pud/pmd_range() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 09/21] loongarch: kvm: remove stack copy address of pXd in pXd_offset() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 12:19 ` sashiko-bot
2026-09-02 12:38 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 10/21] riscv: " Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 11/21] riscv: mm: use proper set_pXd() for generic compile-time folded patable in vmalloc_fault() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 12/21] mm/pgtable: redefine PGTABLE_LEVEL enum with ascend order from PGD Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-10 11:05 ` David Hildenbrand (Arm)
2026-09-10 11:05 ` David Hildenbrand (Arm)
2026-09-10 11:05 ` David Hildenbrand (Arm)
2026-09-02 11:56 ` [PATCH RFC v3 13/21] x86: mm: use pgtable_level enum in effective_prot_pXd() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 20:48 ` Dave Hansen
2026-09-02 20:48 ` Dave Hansen
2026-09-02 20:48 ` Dave Hansen
2026-09-07 8:06 ` Yeoreum Yun
2026-09-07 8:06 ` Yeoreum Yun
2026-09-07 8:06 ` Yeoreum Yun
2026-09-10 11:02 ` David Hildenbrand (Arm)
2026-09-10 11:02 ` David Hildenbrand (Arm)
2026-09-10 11:02 ` David Hildenbrand (Arm)
2026-09-10 15:29 ` Dave Hansen
2026-09-10 15:29 ` Dave Hansen
2026-09-10 15:29 ` Dave Hansen
2026-09-10 11:03 ` David Hildenbrand (Arm)
2026-09-10 11:03 ` David Hildenbrand (Arm)
2026-09-10 11:03 ` David Hildenbrand (Arm)
2026-09-02 11:56 ` [PATCH RFC v3 14/21] x86: mm: carve out the generic compile-time folded pgtable case in effective_prot() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 20:46 ` Dave Hansen
2026-09-02 20:46 ` Dave Hansen
2026-09-02 20:46 ` Dave Hansen
2026-09-10 11:06 ` David Hildenbrand (Arm)
2026-09-10 11:06 ` David Hildenbrand (Arm)
2026-09-10 11:06 ` David Hildenbrand (Arm)
2026-09-02 11:56 ` [PATCH RFC v3 15/21] x86: mm: skip collapse_pud_page() when CONFIG_X86_DIRECT_GBPAGES disabled Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 12:17 ` sashiko-bot
2026-09-02 12:29 ` Yeoreum Yun
2026-09-02 15:38 ` Dave Hansen
2026-09-02 15:38 ` Dave Hansen
2026-09-02 15:38 ` Dave Hansen
2026-09-02 16:48 ` Yeoreum Yun [this message]
2026-09-02 16:48 ` Yeoreum Yun
2026-09-02 16:48 ` Yeoreum Yun
2026-09-10 11:07 ` David Hildenbrand (Arm)
2026-09-10 11:07 ` David Hildenbrand (Arm)
2026-09-10 11:07 ` David Hildenbrand (Arm)
2026-09-02 11:56 ` [PATCH RFC v3 16/21] openrisc/pgtable: drop __pmd_offset() Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 17/21] mm/pgtable: optimize pmdp_get() and friends for folded pagetable levels Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 18/21] mm/pgtable: catch abuse of folded dummy pgd_t/p4d_t/pud_t Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 19/21] mm/pgtable: disallow calling (pgd|p4d|pud)_page, pgd_page_vaddr() and (p4d|pud)_pgtable with dummy Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 20/21] mm/pgtable: disallow calling folded set_pgd/set_p4d/set_pud " Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` [PATCH RFC v3 21/21] Documentation: mm: clarify behaviour of compile-time folded page tables Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-02 11:56 ` Yeoreum Yun
2026-09-10 11:12 ` [PATCH RFC v3 00/21] mm: change behavior of pXdp_get()/pXd_page() in compile-time folded pgtable David Hildenbrand (Arm)
2026-09-10 11:12 ` David Hildenbrand (Arm)
2026-09-10 11:12 ` David Hildenbrand (Arm)
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=aphTTqhf3yO74JoO@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=atish.patra@linux.dev \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=jonas@southpole.se \
--cc=kasong@tencent.com \
--cc=kernel@xen0n.name \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=ljs@kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=maobibo@loongson.cn \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yuanchu@google.com \
--cc=zhaotianrui@loongson.cn \
/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.