Re: Next steps towards shrinking stuct page

[Matthew Wilcox <willy@infradead.org>]

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.