Re: [PATCH v12 2/5] mm/vmalloc: use physical page count for vrealloc() grow-in-place check

[Shivam Kalra]

On 07/05/26 22:51, Uladzislau Rezki wrote:
> On Thu, May 07, 2026 at 01:13:35AM +0530, Shivam Kalra wrote:
> > On 07/05/26 00:17, Uladzislau Rezki wrote:
> > > Maybe we should consider Fujunjie approach and borrow his idea to shrink VA also?
> > > In that case, we do not need to switch to vm->nr_pages? And we do not
> > > need
> > >
> > > [PATCH v12 3/5] mm/vmalloc: use physical page count in vread_iter()
> > >
> > > ?
> > >
> > > --
> > > Uladzislau Rezki
> > I didn't want to change the va in this patch series and wanted to keep
> > it simple.
> > If we change the va, we will also need to rebalance the rb tree.
> > I can work on a followup patch series if VA space pressure is critical.
> Actually it is not critical. The idea is if we shrink VA then we do not
> need care much about the size thus keeping vread_iter() unchanged as
> well as [PATCH v12 2/5]? at least partly.
>
> I am find with it anyway.
>
> Reviewed-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
>
> --
> Uladzislau Rezki

Thanks for the review.

There's actually one more benefit of this approach for a future
grow-in-place optimization: since the VA reservation is kept intact
after a shrink, a subsequent grow wouldn't need to allocate a new
virtual address range or manipulate the vmap_area tree. It could
allocate and map new pages directly into the existing VA range.
So for workloads where shrinking and growing occur frequently,
this approach lays better groundwork.