memcg_data and the page/folio/slab split

[Matthew Wilcox <willy@infradead.org>]

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.