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

[Fujunjie]

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.

Thanks,
fujunjie