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

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

[fujunjie]

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

Thanks.

fujunjie (1):
  mm/vmalloc: reclaim tail resources on large vrealloc() shrink

 mm/vmalloc.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 100 insertions(+), 5 deletions(-)

-- 
2.34.1

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

[Uladzislau Rezki]

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

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

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