Re: [RFC PATCH] mm/sparse: remove sparse_buffer

[Muchun Song <muchun.song@linux.dev>]

> On Apr 9, 2026, at 23:10, Mike Rapoport <rppt@kernel.org> wrote:
> 
> Hi,
> 
> On Thu, Apr 09, 2026 at 02:29:38PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/9/26 13:40, Muchun Song wrote:
>>> 
>>> 
>>>> On Apr 8, 2026, at 21:40, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>>> 
>>>> 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?
>>> 
>>> You raised a very interesting point about whether memblock keeps
>>> these allocations close to each other. I've done a thorough test
>>> on a 16GB VM by printing the actual physical allocations.
> 
> memblock always allocates in order, so if there are no other memblock
> allocations between the calls to memmap_alloc(), all these allocations will
> be together and they all will be coalesced to a single region in
> memblock.reserved.
> 
>>> I enabled the existing debug logs in arch/x86/mm/init_64.c to
>>> trace the vmemmap_set_pmd allocations. Here is what really happens:
>>> 
>>> When using vmemmap_alloc_block without sparse_buffer, the
>>> memblock allocator allocates 2MB chunks. Because memblock
>>> allocates top-down by default, the physical allocations look
>>> like this:
>>> 
>>> [ffe6475cc0000000-ffe6475cc01fffff] PMD -> [ff3cb082bfc00000-ff3cb082bfdfffff] on node 0
>>> [ffe6475cc0200000-ffe6475cc03fffff] PMD -> [ff3cb082bfa00000-ff3cb082bfbfffff] on node 0
>>> [ffe6475cc0400000-ffe6475cc05fffff] PMD -> [ff3cb082bf800000-ff3cb082bf9fffff] on node 0
> 
> ...
> 
>>> Notice that the physical chunks are strictly adjacent to each
>>> other, but in descending order!
>>> 
>>> So, they are NOT "scattered around" the whole node randomly.
>>> Instead, they are packed densely back-to-back in a single
>>> contiguous physical range (just mapped top-down in 2MB pieces).
>>> 
>>> Because they are packed tightly together within the same
>>> contiguous physical memory range, they will at most consume or
>>> pollute the exact same number of memory blocks as a single
>>> contiguous allocation (like sparse_buffer did). Therefore, this
>>> will NOT turn additional memory blocks/sections into an
>>> "un-offlinable" state.
>>> 
>>> It seems we can safely remove the sparse buffer preallocation
>>> mechanism, don't you think?
>> 
>> Yes, what I suspected. Is there a performance implication when doing
>> many individual memmap_alloc(), for example, on a larger system with
>> many sections?
> 
> memmap_alloc() will be slower than sparse_buffer_alloc(), allocating from
> memblock is more involved that sparse_buffer_alloc(), but without
> measurements it's hard to tell how much it'll affect overall sparse_init().

I ran a test on a 256GB VM, and the results are as follows:

	With patch:    741,292 ns
	Without patch: 199,555 ns

The performance is approximately 3.7x slower with the patch applied.

Thanks,
Muchun

> 
>> -- 
>> Cheers,
>> 
>> David
> 
> -- 
> Sincerely yours,
> Mike.