[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

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

[Shivam Kalra]

Hey Fujunjie

In my patch series,
1. I am freeing at least a single page.
2. Did not change the vmap area, only changed the nr_pages at vm_struct
    and update the pages array.

Rest of the questions are addressed in my patch series.

Feel free to review or test my patch series and let me know if you
have any suggestions.

Shivam