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.
