Re: Next steps towards shrinking stuct page

[Matthew Wilcox <willy@infradead.org>]

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;
        }

I think someone (maybe Yosry?) tried to explain this problem to me at
LSFMM, but I didn't understand.

Most of the places that use GFP_KERNEL_ACCOUNT are either page tables
or kmalloc/kvmalloc.  But I think we're going to need a new memdesc
type for accounted memory.

struct accounted_mem {
	unsigned long flags;
	struct obj_cgroup *objcg;
};

(we'll be able to drop MEMCG_DATA_* once we have the memdesc type, but
we need to keep it until we're there).

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.