Re: [RFC] mm/vmalloc: vrealloc() shrink TODO - seeking direction before implementing

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Feb 19, 2026 at 04:36:54AM +0530, Shivam Kalra wrote:
> Hi all,
> 
> I've been looking at the TODO comment introduced in commit 3ddc2fefe6f3
> ("mm: vmalloc: implement vrealloc()"):
> 
> ```c
> /*
>  * TODO: Shrink the vm_area, i.e. unmap and free unused pages. What
>  * would be a good heuristic for when to shrink the vm_area?
>  */
> ```
> 
> Before spending time on an implementation I'd like to check with
> maintainers that the approach is sound.
> 
> Current state
> 
> When vrealloc() shrinks an allocation, it only updates `vm->requested_size`
> and KASAN shadow - no physical pages are freed. This leaves wasted
> pages mapped for the lifetime of the allocation.
> 
> Proposed approach
> 
> When the new size crosses a page boundary, free the tail pages in-place.
> 
> I'm proposing to always shrink when pages can be freed (no threshold
> heuristic), matching the simplicity of krealloc()'s in-place shrink
> approach. For huge-page vmalloc allocations (page_order > 0) I'd skip
> the shrink, since partial freeing would require splitting.
> 
> 
> Questions
> 
>   1. Does the in-place approach (keep `vm->size`, free tail pages) look
>      acceptable, or is there a preferred alternative?
> 
>   2. Is "always shrink when crossing a page boundary" a reasonable
>      heuristic, or would you prefer a threshold (e.g., free only if
>      > N pages are reclaimed)?
> 
>   3. Is skipping huge-page allocations the right call for a first
>      patch, or should it be handled upfront?
> 
I think we have 0 users of vrealloc(). It was added because of Rust folk
wanted this.

From the other hand, if we free some tail pages without saving much in
memory consumption, IMO it does not make sense to introduce more complexity
then. Also, as an example, if you want grow you need to alloc/map back.

I mean it all depends on number of use cases and sensitive to it workloads.

--
Uladzislau Rezki