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

Andrew Morton
2026-04-29T12:04:31Z

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.
>
> 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?

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?