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

[Johannes Weiner <hannes@cmpxchg.org>]

On Wed, Apr 29, 2026 at 03:04:16PM +0200, David Hildenbrand (Arm) wrote:
> On 4/29/26 14:31, Ryan Roberts wrote:
> > On 29/04/2026 13:04, Andrew Morton wrote:
> >> On Wed, 29 Apr 2026 06:33:26 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
> >>
> >>>
> >>> 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...
> 
> Right, that's what Willy has said: allocating+freeing larger blocks, especially
> for unmovable data, reduces fragmentation as a whole. And that theory makes
> sense for me in the context here.

Do we have data confirming that it works out like that?

I think the missing piece is that as long as we still *do* have small
order requests with mixed lifetimes, they will punch holes and cause
fragmentation. Large requests need to clean them up, which is
expensive. You can of course make the argument that it's really the
small requests that are the source of the cost. And I would agree ;)

But adding higher order requests right now surfaces that cost. We've
seen that everytime in real workloads: THP, the large page cache
requests, and now vmalloc. They all increase compaction rates, cause
failures in higher-order network atomics etc.

I do appreciate it's a chicken and egg problem. But I don't think we
can justify regressions from now until there are no more small(er),
fragmenting requests.

So we should still require some form of amortization story when we add
larger requests. It's not accurate to say that they pay for themselves
right now.

And the small cost reduction in the vmalloc alloc path does not offset
the externalities of consuming contiguity, not by a long shot.