Re: [PATCH v2] memcg: cache obj_stock by memcg, not by objcg pointer

[Shakeel Butt]

Cc Alex, Joshua (since they are working on making per-num kmem accounting work)

On Sun, May 17, 2026 at 12:43:08PM -0700, Shakeel Butt wrote:
> Commit 01b9da291c49 ("mm: memcontrol: convert objcg to be per-memcg
> per-node type") split a memcg's single obj_cgroup into one per NUMA
> node, but the per-CPU obj_stock_pcp still keys cached_objcg by
> pointer. Cross-NUMA workloads now see a drain on every refill and a
> miss on every consume that targets a sibling per-node objcg of the
> same memcg, producing the 67.7% stress-ng switch-mq regression
> reported by LKP.
> 
> stock->nr_bytes are fungible across per-node objcgs of one memcg.
> Treat the cache as keyed by memcg in __consume_obj_stock() and
> __refill_obj_stock() so siblings share the reserve. Compare via
> READ_ONCE(objcg->memcg) directly: pointer-compare only, no deref, so
> the rcu_read_lock contract on obj_cgroup_memcg() does not apply.
> 
> In the same-memcg refill path also fold the incoming objcg's
> nr_charged_bytes into the stock; otherwise sub-page residue
> accumulates on whichever sibling was cached at drain time and
> obj_cgroup_release() silently drops it, leaking up to nr_node_ids *
> (PAGE_SIZE - 1) bytes per memcg lifecycle from the page_counter.
> This issue was reported by Sashiko.
> 
> Update the now-stale invariant comment on __account_obj_stock().
> 
> Qi Zheng built a specialized reproducer [1] for the corner case and
> confirmed the fix.
> 
> Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-lkp/202605121641.b6a60cb0-lkp@xxxxxxxxx
> Fixes: 01b9da291c49 ("mm: memcontrol: convert objcg to be per-memcg per-node type")
> Link: https://lore.kernel.org/19693be6-7132-446e-b3fc-b7e9f56e5949@xxxxxxxxx/ [1]
> Signed-off-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>
> Debugged-by: Qi Zheng <qi.zheng@xxxxxxxxx>
> Tested-by: Qi Zheng <qi.zheng@xxxxxxxxx>

Sashiko [1] reported two issues. First one seems benign but the second one is
real. However I think we need to take a step back and rethink on how to solve
this issue in more future proof way.

It seems like Alex and Joshua are working on enabling per-node kmem accounting
and that would need accurate per-numa association for each per-node objcg.
So, checking objcg->memcg in consume and refill, would go against the per-node
kmem accounting.

One way to fix the regression and be future proof is to follow the approach we
have for memcg_stock_pcp which is multiple per-cpu objcg stocks. We will need to
test it more and depending on the additional code complexity, we will need to
decide to backport it to 7.2 or not.


[1] https://sashiko.dev/#/patchset/20260517194308.952655-1-shakeel.butt@xxxxxxxxx?part=1