Re: [PATCH v8 0/7] mm/page_counter: move stock from mem_cgroup to page_counter

[Balbir Singh <balbirs@nvidia.com>]

On Thu, Nov 05, 2026 at 09:50:43AM -0500, Joshua Hahn wrote:
> On Thu, Nov 5, 2026 at 1:17 AM Balbir Singh <balbirs@nvidia.com> wrote:
> >
> > On Wed, Nov 04, 2026 at 03:30:21PM -0800, Joshua Hahn wrote:
> > > INTRODUCTION
> > > ============
> > > Memcg keeps a per-CPU stock of precharged pages so that small and
> > > frequent allocations do not walk the page_counter hierarchy every time.
> > > Today, the stock implementation lives in memcontrol code, even though
> > > the operation it caches is a page_counter charge. This makes it
> > > difficult to add new page_counters to a memcg and preserve the fast path
> > > behavior.
> > >
> > > This series moves the stock into the page_counter layer.
> > > page_counter_try_charge() consumes the stock, charges a batch to the
> > > hierarchy on a miss, and refills the stock with the surplus. Memcg no
> > > longer manages the stock in try_charge_memcg.
> > >
> > > So the stock keeps the existing layout, which is still a per-CPU bank
> > > of 7 slots, each holding a count of precharged pages that it hands out.
> > > It maintains exclusion using local locks on each CPU, and for remote
> > > drains we schedule on the memcg workqueue.
> > >
> > > This change gives us the following benefits:
> > > - Separate charge caching (page_counter) from charge policy (memcg).
> > > - Makes it simple to keep stock out of interior cgroups on cgroup v2.
> > > - Prepares for future work for stock improvement, which can now be
> > >   isolated from memcg changes.
> 
> [...snip...]
> 
> > Is the main motivation ease of addition of page_counters to a memcg?
> > What would those counters be, why not add them here?
> 
> Hi Balbir,
> 
> Thank you for your interest in the series! So yes, that is the main
> motivation but this series offers standalone benefits as well (which
> are right above).
> 
> The new page_counters that I want to add track per-tier per-memcg
> residence. Those are used for enforcement (and not necessarily for
> visibility), so I think they wouldn't make too much sense to add on
> their own now, without the actual enforcement parts.
> 
> What do you think? I've also linked my tiered memcg series [1] if you
> wanted additional context.

Thanks! I'll take a look. I was just curious based on the numbers I saw
in the cover letter and wondering what the changes got, I can see how it
helps in a hierarchial situation.

> 
> Thank you, I hope you have a great day!
> Joshua
> 
> [1] https://lore.kernel.org/all/20260807202059.2620949-1-joshua.hahnjy@gmail.com/

Balbir