On Wed, May 15, 2024 at 5:21 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > For those who couldn't read the text on the wiki page earlier: > > https://kernelnewbies.org/MatthewWilcox/Memdescs > https://kernelnewbies.org/MatthewWilcox/FolioAlloc > https://kernelnewbies.org/MatthewWilcox/BuddyAllocator > https://kernelnewbies.org/MatthewWilcox/Memdescs/Path > > That fourth page is freshly created as a result of the discussions in > the room. I'll continue to refine these pages as my understanding of > various issues improves. > I took a look again at folio->memcg_data. We have three types of pointers that we can put in there: (a) struct mem_cgroup pointer (no flags set, for anon & file folios). (b) struct obj_cgroup pointer (MEMCG_DATA_KMEM set, for non-slab accounted allocations). (c) a vector of struct obj_cgroup pointers (MEMCG_DATA_OBJCGS set, for slab allocations). I believe we should be able to get rid of MEMCG_DATA_OBJCGS now and use a struct obj_cgroup ** directly in struct slab. I see a few places where we change struct slab to struct folio or vice versa, but I don't think they miss with the memcg stuff. The only exception I can find is print_page_owner_memcg(), where we use this flag when printing the memcg of a page to print that it is a slab page (and hence no memcg will be printed). I believe a PageSlab() check may be racy, but I am not sure, and I don't know if we really care. Now for (a) and (b). I believe once struct folio only represents anon and file folios (or if they have separate types), we should be able to use a struct mem_cgroup pointer. This will take care of (a). Things like PerCPU and PageTable fit into category (b) and will have a struct obj_cgroup pointer. The problem is other category (b) allocations that fit into Misc and do not have associated metadata. These allocations should have an associated obj_cgroup pointer if they are accounted, but as far as I can tell we have no place to store it according to the current plan.
