Re: [PATCH v2] mm/percpu, memcontrol: Per-memcg-lruvec percpu accounting

[Harry Yoo (Oracle)]

On Tue, Apr 07, 2026 at 08:40:24PM -0700, Joshua Hahn wrote:
> On Wed, 8 Apr 2026 11:40:27 +0900 "Harry Yoo (Oracle)" <harry@xxxxxxxxxx> wrote:
> > On Fri, Apr 03, 2026 at 08:38:43PM -0700, Joshua Hahn wrote:
> > > diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
> > > index 4f5937090590d..e36b639f521dd 100644
> > > --- a/mm/percpu-vm.c
> > > +++ b/mm/percpu-vm.c
> > > @@ -65,6 +66,10 @@ static void pcpu_free_pages(struct pcpu_chunk *chunk,
> > >  				__free_page(page);
> > >  		}
> > >  	}
> > > +
> > > +	for_each_node(nid)
> > > +		mod_node_page_state(NODE_DATA(nid), NR_PERCPU_B,
> > > +				-1L * nr_pages * nr_cpus_node(nid) * PAGE_SIZE);
> > 
> > Can this end up with mis-accounting due to CPU hotplug?
> 
> Hey Harry, thanks for giving this patch a look!

np :)

> Yes, definitely. I think the solution is just to charge based on possible
> CPUs, even if that might lead to some inaccuracy (by however many CPUs
> aren't online at that moment).

Yeah, that sounds fine to me.
Not sure if there's nr_cpus_node() equivalent for possible CPUs though.

> Seems like that's what already happens
> in memcg anyways, so I think this discrepancy is OK to tolerate.

Agreed.

> Will spin up a v3! Thanks a lot, Harry! Have a great day : -)

You too!

-- 
Cheers,
Harry / Hyeonggon