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

[Shivam Kalra <shivamkalra98@zohomail.in>]

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