On Tue, May 21, 2024 at 12:29:39PM -0700, Shakeel Butt wrote:
> On Tue, May 21, 2024 at 03:44:21PM +0100, Matthew Wilcox wrote:
> > The memcg should not be attached to the individual pages that make up a
> > vmalloc allocation. Rather, it should be managed by the vmalloc
> > allocation itself. I don't have the knowledge to poke around inside
> > vmalloc right now, but maybe somebody else could take that on.
>
> Are you concerned about accessing just memcg or any field of the
> sub-page? There are drivers accessing fields of pages allocated through
> vmalloc. Some details at 3b8000ae185c ("mm/vmalloc: huge vmalloc backing
> pages should be split rather than compound").
Thanks for the pointer, and fb_deferred_io_fault() is already on my
hitlist for abusing struct page.
My primary concern is that we should track the entire allocation as a
single object rather than tracking each page individually. That means
assigning the vmalloc allocation to a memcg rather than assigning each
page to a memcg. It's a lot less overhead to increment the counter once
per allocation rather than once per page in the allocation!
But secondarily, yes, pages allocated by vmalloc probably don't need
any per-page state, other than tracking the vmalloc allocation they're
assigned to. We'll see how that theory turns out.
