Re: [PATCH v6 0/3] mm: Free contiguous order-0 pages efficiently

[Ryan Roberts <ryan.roberts@arm.com>]

On 29/04/2026 13:04, Andrew Morton wrote:
> On Wed, 29 Apr 2026 06:33:26 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
>> On Wed, Apr 01, 2026 at 11:16:18AM +0100, Muhammad Usama Anjum wrote:
>>> Hi All,
>>>
>>> A recent change to vmalloc caused some performance benchmark regressions (see
>>> [1]). I'm attempting to fix that (and at the same time significantly improve
>>> beyond the baseline) by freeing a contiguous set of order-0 pages as a batch.
>>
>> I think we should revert the original patch.
>>
>> The premise is that we can save some allocator calls by requesting
>> higher orders and splitting them up into singles. This is a frivolous
>> and short-sighted use of a very coveted and expensive resource.

I'm not sure it's that simple. First off, vmalloc has preferred to allocate high
order pages for quite a while, it's just that the patch you're referring to
makes it try even harder. So reverting the patch doesn't completely revert the
behaviour, it just reduces it.

Performance benefits because those high order pages are mapped appropriately in
the page table - i.e. 1G PUD, 2M PMD, (or 64K CONTPTE on arm64). So it's not
solely about the number of cycles spent in the allocator; the HW is used more
efficiently. vmalloc only splits to order-0 for the benefit of the caller,
because there are some places that assume they can access each returned struct page.

And all the order-0 pages of the original high order page are freed at the same
time, so it's not like we are destroying the contiguous resource; it remains
intact for the next user (well, ignoring that some will be freed to the pcpu
list - this series solves that wrinkle). I've heard it argued that this approach
is actually _better_ for conserving contiguous blocks because it's keeping the
lifetime of all the constituent pages bound together and reducing fragmentation.
I've never seen any data though...

>>
>> The buddy allocator tries hard to retain contiguity *if it isn't
>> needed by the caller*. This patch actively works around that.
>>>> The cost of recreating those higher orders elsewhere is shouldered by
>> whoever actually needs the contiguity down the line. And that process
>> is orders of magnitudes more expensive than we save here:
>>
>> We're saving cycles per page in the vmalloc path, and later spend tens
>> of thousands of cycles per page to recreate the contiguity. Scanning
>> PFN ranges, folio locks, rmap walks, TLB flushes, page copies.
>>
>> That's a terrible trade-off.
> 
> That's persuasive.
> 
> afaict much/all of this series remains useful after a06157804399
> ("mm/vmalloc: request large order pages from buddy allocator") is
> reverted?

Yes; although the motivation for the investigation was observed micro-benchmark
regressions due to a06157804399 ("mm/vmalloc: request large order pages from
buddy allocator"), this series is still beneficial even without that patch since
vmalloc will still allocate high order pages in many situations and so it's
still beneficial to free them efficiently when the time comes.

> 
> What I'm not understanding is how significant all of this is.  Sure,
> making many-page vmallocs faster is both beneficial and harmful.  And we
> have super-focused microbenchmarks which demonstrate both effects.  But
> how often does the kernel actually *do* this stuff in real-world (or
> even real-world corner-case) situations?

Afraid I don't have clear data on that. My intuition is that it's a real-world
corner case. But significant enough to justify all the previous effort to map by
hugepage where possile...

Thanks,
Ryan