Re: [PATCH 1/2] mm: vmalloc: streamline vmalloc memory accounting
From: Uladzislau Rezki
Date: Tue Feb 24 2026 - 13:22:39 EST
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@xxxxxxxxx>
--
Uladzislau Rezki