All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Wentao Guan <guanwentao@uniontech.com>
Cc: chenhuacai@kernel.org, kernel@xen0n.name,
	loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, akpm@linux-foundation.org, rppt@kernel.org,
	david@kernel.org
Subject: Re: [RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn
Date: Wed, 21 Oct 2026 15:23:21 +0800	[thread overview]
Message-ID: <EB4B2A6B-147E-4E7A-BAD7-A7C4699AF46E@linux.dev> (raw)
In-Reply-To: <20261021062115.116922-1-guanwentao@uniontech.com>



> 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
> 


  reply	other threads:[~2026-10-21  7:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21  6:21 [RFC PATCH] LoongArch: mm: avoid backing vmemmap beyond max_pfn Wentao Guan
2026-10-21  7:23 ` Muchun Song [this message]
2026-10-21 10:13   ` Wentao Guan
2026-10-22  6:22 ` sashiko-bot

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=EB4B2A6B-147E-4E7A-BAD7-A7C4699AF46E@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=david@kernel.org \
    --cc=guanwentao@uniontech.com \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=loongarch@lists.linux.dev \
    --cc=rppt@kernel.org \
    /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.