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

[fujunjie <fujunjie1@qq.com>]

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