linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Muchun Song <songmuchun@bytedance.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: yinghai@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>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/sparse: remove sparse_buffer
Date: Wed, 8 Apr 2026 15:40:21 +0200	[thread overview]
Message-ID: <b22f0af1-848d-45da-99b2-0c28b740e979@kernel.org> (raw)
In-Reply-To: <20260407083951.2823915-1-songmuchun@bytedance.com>

On 4/7/26 10:39, Muchun Song wrote:
> The sparse_buffer was originally introduced in commit 9bdac9142407
> ("sparsemem: Put mem map for one node together.") to allocate a
> contiguous block of memory for all memmaps of a NUMA node.
> 
> However, the original commit message did not clearly state the actual
> benefits or the necessity of keeping all memmap areas strictly
> contiguous for a given node.

We don't want the memmap to be scattered around, given that it is one of
the biggest allocations during boot.

It's related to not turning too many memory blocks/sections
un-offlinable I think.

I always imagined that memblock would still keep these allocations close
to each other. Can you verify if that is indeed true?

-- 
Cheers,

David


      reply	other threads:[~2026-04-08 13:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07  8:39 Muchun Song
2026-04-08 13:40 ` David Hildenbrand (Arm) [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=b22f0af1-848d-45da-99b2-0c28b740e979@kernel.org \
    --to=david@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.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=rppt@kernel.org \
    --cc=songmuchun@bytedance.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=yinghai@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