Re: Next steps towards shrinking stuct page

[David Hildenbrand <david@redhat.com>]

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.

> 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.

But how to do that without a compound page?

-- 
Cheers,

David / dhildenb