From: Mike Rapoport <rppt@kernel.org>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/sparse: Remove sparse buffer pre-allocation mechanism
Date: Sun, 12 Apr 2026 19:26:07 +0300 [thread overview]
Message-ID: <advHn0m0iaQ7d32t@kernel.org> (raw)
In-Reply-To: <20260410092419.2446420-1-songmuchun@bytedance.com>
On Fri, Apr 10, 2026 at 05:24:19PM +0800, Muchun Song wrote:
> Commit 9bdac9142407 ("sparsemem: Put mem map for one node together.")
> introduced a mechanism to pre-allocate a large memory block to hold all
> memmaps for a NUMA node upfront.
>
> However, the original commit message did not clearly state the actual
> benefits or the necessity of explicitly pre-allocating a single chunk
> for all memmap areas of a given node.
>
> One of the concerns about removing this pre-allocation is that the
> subsequent per-section memmap allocations could become scattered around,
> and might turn too many memory blocks/sections into an "un-offlinable"
> state. However, tests show that even without the explicit node-wide
> pre-allocation, memblock still allocates memory closely and
> back-to-back. When tracing vmemmap_set_pmd allocations, the physical
> chunks allocated by memblock are strictly adjacent to each other in a
> single contiguous physical range (mapped top-down). Because they are
> packed tightly together naturally, they will at most consume or pollute
> the exact same number of memory blocks as the explicit pre-allocation
> did.
>
> Another concern is the boot performance impact of calling memmap_alloc()
> multiple times compared to one large node-wide allocation. Tests on a
> 256GB VM showed that memmap allocation time increased from 199,555 ns
> to 741,292 ns. Even though it is 3.7x slower, on a 1TB machine, the
> entire memory allocation time would only take a few milliseconds. This
> boot performance difference is completely negligible.
>
> Since no negative impact on memory offlining behavior or noticeable
> boot performance regression was found, this patch proposes removing
> the explicit node-wide memmap pre-allocation mechanism to reduce the
> maintenance burden.
>
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> Changes in v2:
> - Addressed David Hildenbrand's and Mike Rapoport's concerns from the
> v1 discussion by incorporating the detailed memblock contiguous
> allocation analysis and the boot performance measurements directly
> into the commit message.
> ---
> include/linux/mm.h | 1 -
> mm/sparse-vmemmap.c | 7 +-----
> mm/sparse.c | 58 +--------------------------------------------
> 3 files changed, 2 insertions(+), 64 deletions(-)
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-04-12 16:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 9:24 [PATCH v2] mm/sparse: Remove sparse buffer pre-allocation mechanism Muchun Song
2026-04-12 16:26 ` Mike Rapoport [this message]
2026-04-13 19:02 ` David Hildenbrand (Arm)
2026-04-14 12:11 ` Mike Rapoport
2026-04-14 12:17 ` 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=advHn0m0iaQ7d32t@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@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.