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

[Uladzislau Rezki]

On Fri, May 08, 2026 at 12:36:18AM +0530, Shivam Kalra wrote:
> 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.
>
Fair point, so there are pros and cons.

--
Uladzislau Rezki