Re: [PATCH 1/4] memcg: use mod_node_page_state to update stats
From: Shakeel Butt
Date: Tue Feb 10 2026 - 11:31:44 EST
On Tue, Feb 10, 2026 at 01:08:49PM +0530, Dev Jain wrote:
[...]
>
> >>
> > Oh so it is arm64 specific issue. I tested on x86-64 machine and it solves
> > the little regression it had before. So, on arm64 all this_cpu_ops i.e. without
> > double underscore, uses LL/SC instructions.
> >
> > Need more thought on this.
> >
> >>> Also can you confirm whether my analysis of the regression was correct?
> >>> Because if it was, then this diff looks wrong - AFAIU preempt_disable()
> >>> won't stop an irq handler from interrupting the execution, so this
> >>> will introduce a bug for code paths running in irq context.
> >>>
> >> I was worried about the correctness too, but this_cpu_add() is safe
> >> against IRQs and so the stat will be _eventually_ consistent?
> >>
> >> Ofc it's so confusing! Maybe I'm the one confused.
> > Yeah there is no issue with proposed patch as it is making the function
> > re-entrant safe.
>
> Ah yes, this_cpu_add() does the addition in one shot without read-modify-write.
>
> I am still puzzled whether the original patch was a bug fix or an optimization.
The original patch was a cleanup patch. The memcg stats update functions
were already irq/nmi safe without disabling irqs and that patch did the
same for the numa stats. Though it seems like that is causing regression
for arm64 as this_cpu* ops are expensive on arm64.
> The patch description says that node stat updation uses irq unsafe interface.
> Therefore, we had foo() calling __foo() nested with local_irq_save/restore. But
> there were code paths which directly called __foo() - so, your patch fixes a bug right
No, those places were already disabling irqs and should be fine.
I am working on adding batched stats update functionality in the hope
that will fix the regression.
>