memcg_data and the page/folio/slab split

memcg_data and the page/folio/slab split

[Matthew Wilcox]

I started working on 'struct acctmem' as hinted at in
https://kernelnewbies.org/MatthewWilcox/Memdescs

However, as I did so, I became aware of two things.  First, we don't
need acctmem until (unless?) we remove page->flags, which is not
on the cards for 2025.  Second, we actually have distinct things stored
in memcg_data and those things line up perfectly with page/slab/folio.

That is, alloc_page(GFP_ACCOUNT) always stores an obj_cgroup pointer there
(with the KMEM flag set).  Slab always stores an slabobj_ext pointer (with
the OBJEXTS flag set) and folios always store a mem_cgroup pointer there.
Maybe that's obvious to those who work on memcg, but I didn't know that;
I just saw code that could handle all three kinds of accounting.

So, new plan.  For 2025, we have struct slab directly pointing
to slabobj_ext (with no flag, because we know anything that is a
slab has this pointer).  struct folio directly points to mem_cgroup.
And alloc_page(GFP_ACCOUNT) uses page->memdesc with a type in the bottom
four bits to say that this is a pointer to an obj_cgroup.

Obviously we don't have a page->memdesc yet, so we'll keep storing
pointers in page->memcg_data until we're ready to switch over.  But I
do have a few patches to separate out GFP_ACCOUNT allocations from
folio allocations that I think are worth merging now, and I'll send
those imminently (think of this as a [-1/n] email).  We can't get
rid of all the "handle any kind of accounting" code today because we
lose information about whether this memory is a file/anon folio vs a
GFP_ACCOUNT allocation in the freeing path.  That's a today problem that
will get solved, but not in this patchset.

Re: memcg_data and the page/folio/slab split

[Shakeel Butt]

On Thu, Mar 13, 2025 at 02:48:44PM +0000, Matthew Wilcox wrote:
> I started working on 'struct acctmem' as hinted at in
> https://kernelnewbies.org/MatthewWilcox/Memdescs
> 
> However, as I did so, I became aware of two things.  First, we don't
> need acctmem until (unless?) we remove page->flags, which is not
> on the cards for 2025.  Second, we actually have distinct things stored
> in memcg_data and those things line up perfectly with page/slab/folio.
> 
> That is, alloc_page(GFP_ACCOUNT) always stores an obj_cgroup pointer there
> (with the KMEM flag set).  Slab always stores an slabobj_ext pointer (with
> the OBJEXTS flag set) and folios always store a mem_cgroup pointer there.
> Maybe that's obvious to those who work on memcg, but I didn't know that;
> I just saw code that could handle all three kinds of accounting.

To be fair I often get confused on page vs folio distinction which your
new following plan and the series will make much more clear.

> 
> So, new plan.  For 2025, we have struct slab directly pointing
> to slabobj_ext (with no flag, because we know anything that is a
> slab has this pointer).  struct folio directly points to mem_cgroup.
> And alloc_page(GFP_ACCOUNT) uses page->memdesc with a type in the bottom
> four bits to say that this is a pointer to an obj_cgroup.
> 
> Obviously we don't have a page->memdesc yet, so we'll keep storing
> pointers in page->memcg_data until we're ready to switch over.  But I
> do have a few patches to separate out GFP_ACCOUNT allocations from
> folio allocations that I think are worth merging now, and I'll send
> those imminently (think of this as a [-1/n] email).  We can't get
> rid of all the "handle any kind of accounting" code today because we
> lose information about whether this memory is a file/anon folio vs a
> GFP_ACCOUNT allocation in the freeing path.  That's a today problem that
> will get solved, but not in this patchset.
> 
> 

Thanks a lot of this awesome work.