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.
