Re: [RFC PATCH 0/1] mm/vmalloc: reclaim tail resources on large vrealloc() shrink

[Uladzislau Rezki]

On Tue, Apr 28, 2026 at 12:38:59AM +0800, Fujunjie wrote:
> 
> 
> On Tue, Apr 28, 2026 at 00:29, Uladzislau Rezki wrote:
> > On Sun, Apr 26, 2026 at 05:28:56AM +0000, fujunjie wrote:
> >> Hi,
> >>
> >> This RFC explores closing the resource retention gap in the vmalloc-backed
> >> shrink path of vrealloc().
> >>
> >> Today, when a vmalloc-backed allocation is shrunk, vrealloc() updates the
> >> requested size but can keep most of the old vmalloc mapping and backing pages
> >> alive. For sufficiently large shrink operations, this can retain a large amount
> >> of tail resources even though the logical object became much smaller.
> >>
> >> This first RFC keeps the scope intentionally conservative:
> >>
> >> - only ordinary VM_ALLOC areas
> >> - only page_order == 0 allocations
> >> - skip more complex vmalloc object types
> >> - only reclaim tail resources when the retained waste is at least PMD_SIZE
> >>
> >> The current evidence supports this as a resource reclamation fix rather than a
> >> workload-tuned performance optimization. Local validation currently covers:
> >>
> >> - synthetic large shrink correctness
> >> - shrink-then-grow regression
> >> - threshold boundary correctness for the current heuristic
> >> - KASAN run-rootfs vmalloc_oob regression coverage
> >>
> >> I would especially appreciate feedback on:
> >>
> >> 1. whether this shrink direction is desirable upstream at all
> >> 2. whether the initial object-type restrictions are reasonable
> >> 3. whether a conservative PMD_SIZE threshold is an acceptable first heuristic
> >> 4. what kind of in-tree regression test would be preferred
> >>
> > Could you please have a look at this work:
> > https://lore.kernel.org/all/20260420-vmalloc-shrink-v11-0-cad80b00853a@xxxxxxxxxxx/
> > 
> > Shivam is working on the same feature. Could you please check?
> > 
> > --
> > Uladzislau Rezki
> 
> Thanks for the pointer, and sorry for missing Shivam's series before sending this RFC.
> 
> I will read through it first and avoid duplicating the effort.
>
Thank you!

Maybe Shivam can also have a look at your work. I put him into To.

--
Uladzislau Rezki