linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


      reply	other threads:[~2026-04-12 16:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10  9:24 Muchun Song
2026-04-12 16:26 ` Mike Rapoport [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox