[RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn

[RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn

[Wentao Guan]

A PMD maps 32MiB of vmemmap on LoongArch with 16KiB base pages, while a
512MiB section only needs 2MiB.  vmemmap_populate() is called for each
section and vmemmap_populate_hugepages() installs a PMD mapping for the
whole PMD, so the last PMD also backs struct pages for PFNs beyond
max_pfn.

On a 34GiB system 160MiB of vmemmap is mapped although 136MiB is
needed.  The extra 24MiB describes PFNs that do not exist.

Other architectures handle this differently.  On x86, arm64 with 4KiB
pages, and riscv, the PMD covers exactly one section's vmemmap, so the
huge page path never maps beyond the populated range; x86 tracks
partially used PMDs with PAGE_UNUSED for memory hotremove.  arm64 uses
base pages for 16KiB and 64KiB kernels.  s390 deliberately keeps using
1MiB frames even for partially used PMDs because vmemmap_populate() is
called per section and falling back would add page tables.  powerpc
radix falls back to base pages only when the altmap cannot back a full
PMD or the allocation fails, and powerpc hash maps the vmemmap with the
linear mapping page size, which can exceed a section as well.

With 16KiB pages the LoongArch PMD is 16 times the vmemmap of one
section.  Moving the whole vmemmap to base pages, as arm64 does for
16KiB and 64KiB, would also remove the tail, but it would give up PMD
mappings for the 128MiB that is fully populated.  Use base pages only
for the PMD that extends beyond pfn_to_page(max_pfn) and keep huge
mappings for the rest.

The altmap case is left alone because max_pfn does not describe it.

Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
 arch/loongarch/mm/init.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 4b46c5d30708d..bb7a17bdb0e51 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -146,6 +146,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end,
 #if CONFIG_PGTABLE_LEVELS == 2
 	return vmemmap_populate_basepages(start, end, node, NULL);
 #else
+	unsigned long vmemmap_end = (unsigned long)pfn_to_page(max_pfn);
+
+	if (!altmap && (start & PMD_MASK) + PMD_SIZE > vmemmap_end)
+		return vmemmap_populate_basepages(start, end, node, NULL);
+
 	return vmemmap_populate_hugepages(start, end, node, NULL);
 #endif
 }
-- 
2.39.5

Re: [RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn

[Muchun Song]

> On Oct 21, 2026, at 14:21, Wentao Guan <guanwentao@uniontech.com> wrote:
> 
> A PMD maps 32MiB of vmemmap on LoongArch with 16KiB base pages, while a
> 512MiB section only needs 2MiB.  vmemmap_populate() is called for each
> section and vmemmap_populate_hugepages() installs a PMD mapping for the
> whole PMD, so the last PMD also backs struct pages for PFNs beyond
> max_pfn.
> 
> On a 34GiB system 160MiB of vmemmap is mapped although 136MiB is
> needed.  The extra 24MiB describes PFNs that do not exist.

Your commit messages are very detailed, but I don't really understand the
problem you're trying to solve. What issue did you run into, and what was
the resulting impact?

Thanks,
Muchun

> 
> Other architectures handle this differently.  On x86, arm64 with 4KiB
> pages, and riscv, the PMD covers exactly one section's vmemmap, so the
> huge page path never maps beyond the populated range; x86 tracks
> partially used PMDs with PAGE_UNUSED for memory hotremove.  arm64 uses
> base pages for 16KiB and 64KiB kernels.  s390 deliberately keeps using
> 1MiB frames even for partially used PMDs because vmemmap_populate() is
> called per section and falling back would add page tables.  powerpc
> radix falls back to base pages only when the altmap cannot back a full
> PMD or the allocation fails, and powerpc hash maps the vmemmap with the
> linear mapping page size, which can exceed a section as well.
> 
> With 16KiB pages the LoongArch PMD is 16 times the vmemmap of one
> section.  Moving the whole vmemmap to base pages, as arm64 does for
> 16KiB and 64KiB, would also remove the tail, but it would give up PMD
> mappings for the 128MiB that is fully populated.  Use base pages only
> for the PMD that extends beyond pfn_to_page(max_pfn) and keep huge
> mappings for the rest.
> 
> The altmap case is left alone because max_pfn does not describe it.
> 
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> ---
> arch/loongarch/mm/init.c | 5 +++++
> 1 file changed, 5 insertions(+)
> 
> diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
> index 4b46c5d30708d..bb7a17bdb0e51 100644
> --- a/arch/loongarch/mm/init.c
> +++ b/arch/loongarch/mm/init.c
> @@ -146,6 +146,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end,
> #if CONFIG_PGTABLE_LEVELS == 2
> 	return vmemmap_populate_basepages(start, end, node, NULL);
> #else
> + 	unsigned long vmemmap_end = (unsigned long)pfn_to_page(max_pfn);
> +
> + 	if (!altmap && (start & PMD_MASK) + PMD_SIZE > vmemmap_end)
> + 		return vmemmap_populate_basepages(start, end, node, NULL);
> +
> 	return vmemmap_populate_hugepages(start, end, node, NULL);
> #endif
> }
> -- 
> 2.39.5
> 

Re: [RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn

[Wentao Guan]

> > On Oct 21, 2026, at 14:21, Wentao Guan <guanwentao@uniontech.com> wrote:
> >
> > A PMD maps 32MiB of vmemmap on LoongArch with 16KiB base pages, while a
> > 512MiB section only needs 2MiB.  vmemmap_populate() is called for each
> > section and vmemmap_populate_hugepages() installs a PMD mapping for the
> > whole PMD, so the last PMD also backs struct pages for PFNs beyond
> > max_pfn.
> >
> > On a 34GiB system 160MiB of vmemmap is mapped although 136MiB is
> > needed.  The extra 24MiB describes PFNs that do not exist.
> 
> Your commit messages are very detailed, but I don't really understand the
> problem you're trying to solve. What issue did you run into, and what was
> the resulting impact?
The commit message is misunderstanding, the issue is point to save memory cost,

> > On a 34GiB system 160MiB of vmemmap is mapped although 136MiB is
> > needed.  The extra 24MiB describes PFNs that do not exist.
On a 32GiB system the platform memory map leaves a 2GiB MMIO window
(serial 10080000,ACPI 100d0000,LOON000x... etc,)
below 4GiB and RAM ends at 34GiB, so max_pfn spans 34GiB.  The vmemmap
for that PFN range is 136MiB, but 160MiB is mapped; the extra 24MiB
describes PFNs that do not exist. In 8GB system, the cost is 0.37% (30MB/8GB).

BRs
Wentao Guan

Log:
 cat /proc/iomem 
00200000-0edfffff : System RAM
  00200000-01b6ffff : Kernel code
  01b70000-03c113ff : Kernel data
  03c11400-03d36caf : Kernel bss
  03d36cb0-03d3ffff : Reserved
  03d40000-03f4bfff : Reserved
10080000-100800ff : serial
10080100-100801ff : serial
10080200-100802ff : serial
10080300-100803ff : serial
10090000-10090007 : LOON0004:00
  10090000-10090007 : LOON0004:00 LOON0004:00
10090100-10090107 : LOON0004:01
  10090100-10090107 : LOON0004:01 LOON0004:01
10090200-10090207 : LOON0004:02
  10090200-10090207 : LOON0004:02 LOON0004:02
10090300-10090307 : LOON0004:03
  10090300-10090307 : LOON0004:03 LOON0004:03
10090400-10090407 : LOON0004:04
  10090400-10090407 : LOON0004:04 LOON0004:04
10090500-10090507 : LOON0004:05
  10090500-10090507 : LOON0004:05 LOON0004:05
100a0000-100a000f : LOON0006:00
  100a0000-100a000f : LOON0006:00 LOON0006:00
100a0100-100a010f : LOON0006:01
  100a0100-100a010f : LOON0006:01 LOON0006:01
100a0200-100a020f : LOON0006:02
  100a0200-100a020f : LOON0006:02 LOON0006:02
100a0300-100a030f : LOON0006:03
  100a0300-100a030f : LOON0006:03 LOON0006:03
100d000c-100d0013 : ACPI PM1a_EVT_BLK
100d0014-100d0017 : ACPI PM1a_CNT_BLK
100d0018-100d001b : ACPI PM_TMR
100d0028-100d002f : ACPI GPE0_BLK
100d0100-100d01ff : LOON0001:00
  100d0100-100d01ff : LOON0001:00 LOON0001:00
100e0000-100e0bff : LOON0002:00
  100e0000-100e0bff : LOON0002:00 LOON0002:00
1fe001e0-1fe001e7 : serial
90400000-f9b7ffff : System RAM
  ea4f0000-f7a9ffff : Reserved
  f9acc000-f9acffff : Reserved
  f9b00000-f9b7ffff : Reserved
f9b90000-fdabffff : System RAM
  f9b90000-f9bbffff : Reserved
fe080000-87fffffff : System RAM
  873800000-874023fff : Reserved
  874400000-874423fff : Reserved
  874800000-874823fff : Reserved
  874c00000-874c23fff : Reserved
  875000000-875023fff : Reserved
  875400000-875423fff : Reserved
  875800000-875823fff : Reserved
  875c00000-875c23fff : Reserved
  876000000-87dffffff : Reserved
  87e240000-87ff93fff : Reserved
  87ff94000-87ff97fff : Reserved
  87ff98000-87ff9bfff : Reserved
  87ff9c000-87ff9ffff : Reserved
  87ffa0000-87ffa3fff : Reserved
  87ffa4000-87ffa7fff : Reserved
  87ffa8000-87ffabfff : Reserved
  87ffac000-87ffaffff : Reserved
  87ffb0000-87ffb3fff : Reserved
  87ffb4000-87ffb7fff : Reserved
  87ffb8000-87ffbbfff : Reserved
  87ffbc000-87ffbffff : Reserved
  87ffc0000-87ffc3fff : Reserved
  87ffc4000-87ffc7fff : Reserved
  87ffc8000-87ffcbfff : Reserved
  87ffcc000-87ffcffff : Reserved
  87ffd0000-87ffd3fff : Reserved
  87ffd4000-87ffd7fff : Reserved
  87ffd8000-87ffdbfff : Reserved
  87ffdc000-87ffdffff : Reserved
  87ffe0000-87ffe3fff : Reserved
  87ffe4000-87ffe7fff : Reserved
  87ffe8000-87ffebfff : Reserved
  87ffec000-87ffeffff : Reserved
  87fff0000-87fff3fff : Reserved
  87fff4000-87fff7fff : Reserved
  87fff8000-87fffbfff : Reserved
  87fffc000-87fffffff : Reserved
e0030000000-e007fffffff : PCI Bus 0000:00
  e0030000000-e00300fffff : PCI Bus 0000:02
    e0030000000-e0030003fff : 0000:02:00.0
    e0030004000-e0030004fff : 0000:02:00.0
      e0030004000-e0030004fff : r8169
  e0030100000-e00301007ff : 0000:00:1a.0
  e0030100800-e0030100bff : 0000:00:08.0
    e0030100800-e0030100bff : ahci
e8000000000-efcffffffff : PCI Bus 0000:00
  e8000000000-e800fffffff : 0000:00:06.0
    e8000000000-e80007ebfff : BOOTFB
      e8000000000-e80007ebfff : simpledrm
  e8010000000-e8013ffffff : 0000:00:1a.0
  e8014000000-e8014ffffff : 0000:00:16.0
  e8015000000-e80150fffff : 0000:00:19.0
    e8015000000-e80150fffff : xhci-hcd
  e8015100000-e801510ffff : 0000:00:06.0
  e8015110000-e801511ffff : 0000:00:06.1
  e8015120000-e801512ffff : 0000:00:06.2
    e8015120000-e801512ffff : ICH HD audio
  e8015130000-e801513ffff : 0000:00:07.0
    e8015130000-e801513ffff : ICH HD audio
  e8015140000-e8015147fff : 0000:00:03.0
    e8015140000-e8015147fff : dwmac-loongson-pci
  e8015148000-e801514ffff : 0000:00:04.0
    e8015148000-e801514ffff : ohci_hcd
  e8015150000-e8015157fff : 0000:00:04.1
    e8015150000-e8015157fff : ehci_hcd
  e8015158000-e801515ffff : 0000:00:05.0
    e8015158000-e801515ffff : ohci_hcd
  e8015160000-e8015167fff : 0000:00:05.1
    e8015160000-e8015167fff : ehci_hcd
  e8015168000-e8015168fff : 0000:00:09.0
  e8015169000-e8015169fff : 0000:00:0a.0
  e801516a000-e801516afff : 0000:00:0b.0
  e801516b000-e801516bfff : 0000:00:0c.0
  e801516c000-e801516cfff : 0000:00:0d.0
  e801516d000-e801516dfff : 0000:00:0f.0
  e801516e000-e801516efff : 0000:00:10.0
  e801516f000-e801516ffff : 0000:00:13.0
  e8015170000-e8015170fff : 0000:00:16.0
    e8015170000-e8015170fff : 0000:00:16.0
  e8015171000-e80151713ff : 0000:00:1a.0
  e8015171400-e80151714ff : 0000:00:06.0
efe00000000-efe1fffffff : PCI ECAM

Re: [RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] loongarch/mm: leaf PMD dereferenced as PTE table in vmemmap_populate()
- [Medium] LoongArch: mm: vmemmap_populate() forces basepages for hotplugged memory above boot max_pfn
- [Medium] LoongArch: mm: unnecessary basepage vmemmap fallback in vmemmap_populate()
--

commit 6672ecaf8ad946ad85463c3a10b46da193101efe
Author: Wentao Guan <guanwentao@uniontech.com>

LoongArch: mm: avoid backing vmemmap beyond max_pfn

This commit changes vmemmap_populate() on LoongArch to fall back to
vmemmap_populate_basepages() when !altmap and the PMD covering start
extends beyond pfn_to_page(max_pfn), avoiding PMD hugepage mappings that
extend past max_pfn.

> diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
> index f801f7097f037..8c33744b93fae 100644
> --- a/arch/loongarch/mm/init.c
> +++ b/arch/loongarch/mm/init.c
> @@ -146,6 +146,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end,
>  #if CONFIG_PGTABLE_LEVELS == 2
>  	return vmemmap_populate_basepages(start, end, node, NULL);
>  #else
> +	unsigned long vmemmap_end = (unsigned long)pfn_to_page(max_pfn);

[Severity: Medium]
How does this check behave when memory is hot-added above initial boot DRAM?

On LoongArch, max_pfn is only initialized during early boot from
PFN_DOWN(memblock_end_of_DRAM()) in arch/loongarch/kernel/mem.c:

void __init memblock_init(void)
{
	...
	max_pfn = PFN_DOWN(memblock_end_of_DRAM());

and in arch/loongarch/kernel/setup.c:

static void __init arch_mem_init(char **cmdline_p)
{
	/* Recalculate max_low_pfn for "mem=xxx" */
	max_pfn = PFN_DOWN(memblock_end_of_DRAM());

When memory is hot-added at runtime via:

  arch_add_memory()
    __add_pages()
      sparse_add_section()
        section_activate()
          populate_section_memmap()
            __populate_section_memmap()
              vmemmap_populate()

or via memremap_pages() without an altmap at physical addresses above boot
DRAM (pfn >= max_pfn), max_pfn is never updated, so start >= vmemmap_end and
(!altmap && (start & PMD_MASK) + PMD_SIZE > vmemmap_end) is unconditionally
true.

Since get_order(PMD_SIZE) <= MAX_PAGE_ORDER on 64-bit LoongArch across 4KiB,
16KiB, and 64KiB page sizes, vmemmap_populate_hugepages() can allocate
PMD_SIZE blocks at runtime. Won't comparing against max_pfn unintentionally
force all non-altmap hotplugged memory above boot DRAM to fall back to
vmemmap_populate_basepages()?

[Severity: Medium]
Should vmemmap_end be aligned up to PAGES_PER_SECTION and gated on PMD_SIZE
exceeding the section vmemmap size?

During early boot, sparse_metadata_init_nid() in mm/sparse.c always populates
a full PAGES_PER_SECTION range for every present section:

	for_each_early_section_nr(start_section_nr, section_nr) {
		...
		mem_map = __populate_section_memmap(pfn, PAGES_PER_SECTION, nid,
						    NULL, NULL);

So falling back to vmemmap_populate_basepages(start, end, node, NULL) still
populates the entire section up to SECTION_ALIGN_UP(max_pfn). However, in
memblock_init() in arch/loongarch/kernel/mem.c, EFI_RESERVED_TYPE and
EFI_RUNTIME_SERVICES_* regions at the top of DRAM are only passed to
memblock_reserve() (not memblock_add()), or DRAM may be capped with mem=,
leaving max_pfn unaligned inside the final section of a PMD. If all 16
sections of a 32MiB PMD on a 16KiB page kernel are present, but max_pfn is
unaligned within the 16th section, (start & PMD_MASK) + PMD_SIZE > vmemmap_end
is true for all 16 sections even though the entire 32MiB PMD is populated,
allocating an extra PTE page table page and losing the PMD mapping while
saving zero vmemmap pages.

Additionally, on 4KiB page kernels (CONFIG_4KB_3LEVEL and CONFIG_4KB_4LEVEL),
SECTION_SIZE_BITS in arch/loongarch/include/asm/sparsemem.h is 29 (512MiB, or
131072 pages), so one section's vmemmap is 8MiB, spanning four 2MiB PMDs.
vmemmap_populate_hugepages() never maps past the section end on 4KiB page
kernels, yet if max_pfn falls within the first 2MiB PMD of the last section,
(start & PMD_MASK) + PMD_SIZE > vmemmap_end forces the entire 8MiB section to
use 4KiB base pages instead of four 2MiB PMDs.

> +
> +	if (!altmap && (start & PMD_MASK) + PMD_SIZE > vmemmap_end)
> +		return vmemmap_populate_basepages(start, end, node, NULL);
> +
>  	return vmemmap_populate_hugepages(start, end, node, NULL);

[Severity: High]
Can calling vmemmap_populate_basepages() here dereference a leaf huge PMD as a
PTE page table pointer and crash the kernel?

In arch/loongarch/mm/init.c, vmemmap_set_pmd() installs a leaf huge PMD
containing a shifted physical PFN and hardware page flags:

void __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node,
			       unsigned long addr, unsigned long next)
{
	pmd_t entry;

	entry = pfn_pmd(virt_to_pfn(p), PAGE_KERNEL);
	pmd_val(entry) |= _PAGE_HUGE | _PAGE_HGLOBAL;
	set_pmd_at(&init_mm, addr, pmd, entry);
}

whereas a non-leaf PMD on LoongArch stores the kernel virtual address of the
PTE table (arch/loongarch/include/asm/pgtable.h):

static inline int pmd_none(pmd_t pmd)
{
	return pmd_val(pmd) == (unsigned long)invalid_pte_table;
}
...
#define pmd_page_vaddr(pmd)	pmd_val(pmd)

While vmemmap_populate_hugepages() checks vmemmap_check_pmd() before reusing
an existing PMD, vmemmap_populate_basepages() in mm/sparse-vmemmap.c calls
vmemmap_pmd_populate() and then vmemmap_pte_populate():

static pmd_t * __meminit vmemmap_pmd_populate(pud_t *pud, unsigned long addr, int node)
{
	pmd_t *pmd = pmd_offset(pud, addr);
	if (pmd_none(*pmd)) {
		...
	}
	return pmd;
}

static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
		struct vmem_altmap *altmap)
{
	pte_t *pte = pte_offset_kernel(pmd, addr);
	unsigned long pfn = page_to_pfn((struct page *)addr);

	if (pte_none(ptep_get(pte))) {

If *pmd is already a leaf huge PMD, pmd_none(*pmd) is false, so
vmemmap_pmd_populate() returns the leaf PMD unchanged and
vmemmap_pte_populate() treats pmd_val(*pmd) as a kernel virtual address in
pte_offset_kernel() and dereferences it in ptep_get(pte).

Because vmemmap_populate() passes NULL for altmap to both helpers and
vmemmap_free() in arch/loongarch/mm/init.c is a no-op, a leaf huge PMD can
already be present when vmemmap_populate_basepages() runs in two ways:

1. In a PMD straddling or above max_pfn, populating a range with
   altmap != NULL (for example via memremap_pages() -> arch_add_memory() ->
   __add_pages() -> sparse_add_section()) skips the !altmap branch and calls
   vmemmap_populate_hugepages(start, end, node, NULL), which installs a leaf
   huge PMD covering the entire PMD (up to 16 sections on 16KiB pages). A
   subsequent population in the same PMD with altmap == NULL (via add_memory()
   or memremap_pages() without altmap, or after memunmap_pages() since
   vmemmap_free() is a no-op) then takes the vmemmap_populate_basepages() path
   on that existing leaf huge PMD.

2. On 4KiB page kernels, a 512MiB section's vmemmap is 8MiB (four 2MiB PMDs).
   When max_pfn falls in the 2nd, 3rd, or 4th PMD of the last section,
   (start & PMD_MASK) + PMD_SIZE > vmemmap_end only tests the first 2MiB PMD
   (which is <= vmemmap_end), so vmemmap_populate_hugepages() installs leaf
   huge PMDs for all four PMDs (also still mapping vmemmap beyond max_pfn in
   the trailing PMDs). If that section is later hot-removed (leaving the four
   leaf huge PMDs in place because vmemmap_free() is empty) and a range
   starting in one of the trailing PMDs above vmemmap_end is populated with
   altmap == NULL, (start & PMD_MASK) + PMD_SIZE > vmemmap_end is true and
   vmemmap_populate_basepages() runs against the existing leaf huge PMD.

>  #endif
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021062115.116922-1-guanwentao@uniontech.com?part=1