Re: [PATCH 1/2] mm: vmalloc: streamline vmalloc memory accounting

[Uladzislau Rezki <urezki@gmail.com>]

On Mon, Feb 23, 2026 at 03:19:20PM -0500, Johannes Weiner wrote:
> On Mon, Feb 23, 2026 at 04:30:32PM +0100, Uladzislau Rezki wrote:
> > On Fri, Feb 20, 2026 at 02:10:34PM -0500, Johannes Weiner wrote:
> > > @@ -3655,6 +3649,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> > >  			continue;
> > >  		}
> > >  
> > > +		mod_node_page_state(page, NR_VMALLOC, 1 << large_order);
> > > +
> > >  		split_page(page, large_order);
> > >  		for (i = 0; i < (1U << large_order); i++)
> > >  			pages[nr_allocated + i] = page + i;
> > > @@ -3675,6 +3671,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> > >  	if (!order) {
> > >  		while (nr_allocated < nr_pages) {
> > >  			unsigned int nr, nr_pages_request;
> > > +			int i;
> > >  
> > >  			/*
> > >  			 * A maximum allowed request is hard-coded and is 100
> > > @@ -3698,6 +3695,9 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> > >  							nr_pages_request,
> > >  							pages + nr_allocated);
> > >  
> > > +			for (i = nr_allocated; i < nr_allocated + nr; i++)
> > > +				inc_node_page_state(pages[i], NR_VMALLOC);
> > > +
> > >  			nr_allocated += nr;
> > >  
> > >  			/*
> > > @@ -3722,6 +3722,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> > >  		if (unlikely(!page))
> > >  			break;
> > >  
> > > +		mod_node_page_state(page, NR_VMALLOC, 1 << order);
> > > +
> > >  		/*
> > Can we move *_node_page_stat() to the end of the vm_area_alloc_pages()?
> > 
> > Or mod_node_page_state in first place should be invoked on high-order
> > page before split(to avoid of looping over small pages afterword)?
> > 
> > I mean it would be good to place to the one solid place. If it is possible
> > of course.
> 
> Note that the top one in the fast path IS called before the
> split. We're accounting in the same step size as the page allocator
> can give us.
> 
> In the fallback paths (bulk allocator, and one-by-one loop), the issue
> is that the individual pages could be coming from different nodes, so
> they need to bump different counters. One possible solution would be
> to remember the last node and accumulate until it differs, then flush:
> 
> fallback_loop() {
> 	page = alloc_pages();
> 	nid = page_to_nid(page);
> 	if (nid != last_nid) {
> 		if (node_count) {
> 			mod_node_page_state(...);
> 			node_count = 0;
> 		}
> 		last_nid = nid;
> 	}
> }
> 
> if (node_count)
> 	mod_node_page_state(...);
> 
> But it IS the slow path, and these are fairly cheap per-cpu
> counters. Especially compared to the cost of calling into the
> allocator. So I'm not sure it's worth it... What do you think?
>
I see. I agree it is easier to keep original solution. I see that
Andrew took it, but just in case:

Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki