On Fri, Oct 18, 2024 at 01:07:43PM +0200, David Hildenbrand wrote:
> On 18.10.24 12:46, Matthew Wilcox wrote:
> > On Tue, Oct 08, 2024 at 04:16:39PM +0200, David Hildenbrand wrote:
> > > >
> > > > 4. Make sure that we're good with memcg_data. I think we are (it's only
> > > > used in folios and slabs today, I _think_), but it'll be good to be
> > > > sure. Someone who understands memcg better than I do can probably find
> > > > some stuff to clean up.
> > >
> > > Last time I looked at this (1month ago), I had the same impression.
> >
> > I took a shot at this. The problem is mm/page_alloc.c:
> >
> > __alloc_pages_noprof:
> > if (memcg_kmem_online() && (gfp & __GFP_ACCOUNT) && page &&
> > unlikely(__memcg_kmem_charge_page(page, gfp, order) != 0)) {
> > __free_pages(page, order);
> > page = NULL;
> > }
> >
>
> Right, I recall that we are only touching the first page. IIRC, it's not
> necessarily a compound page.
That fits with how split_page_memcg() operates.
> > struct accounted_mem {
> > unsigned long flags;
> > struct obj_cgroup *objcg;
> > };
[...]
> > So I guess that's my next step -- adding:
> >
> > struct accounted_mem {
> > unsigned long flags;
> > unsigned long padding[5];
> > unsigned int padding2[2];
> > unsigned long objcg;
> > };
> >
> > and the various assertions that objcg & flags occupy the same bytes in
> > accounted_mem as they do in page, until we separate them entirely.
>
> But how to do that without a compound page?
The first step is just an exercise in typing. We'll use the exact same
bits for the exact same purpose, just eliminating all references to
page->memcg_data. Later, we'll progress to separately allocating a
16-byte accounted_mem.
