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

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

[Shivam Kalra]

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?


Thanks in advance for any guidance

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

[Uladzislau Rezki]

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

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

[Danilo Krummrich]

(Cc: Alice)

On Thu Feb 19, 2026 at 5:57 PM CET, Uladzislau Rezki wrote:
> I think we have 0 users of vrealloc(). It was added because of Rust folk
> wanted this.

We just gained a user with the Rust binder driver.

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

[Alice Ryhl]

On Thu, Feb 19, 2026 at 06:01:29PM +0100, Danilo Krummrich wrote:
> (Cc: Alice)
> 
> On Thu Feb 19, 2026 at 5:57 PM CET, Uladzislau Rezki wrote:
> > I think we have 0 users of vrealloc(). It was added because of Rust folk
> > wanted this.
> 
> We just gained a user with the Rust binder driver.

Yeah, if I have a long-lived resizable array (allocated with kvmalloc)
then I'd like to be able to shrink it if the number of elements decrease
again, to prevent unnecessary indefinite memory usage.

Alice