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

[Uladzislau Rezki <urezki@gmail.com>]

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@zohomail.in/

Shivam is working on the same feature. Could you please check?

--
Uladzislau Rezki