From: Yosry Ahmed <yosryahmed@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org
Subject: Re: Memdesc wiki pages
Date: Wed, 15 May 2024 19:28:30 -0700 [thread overview]
Message-ID: <CAJD7tkZt-hrnrexBwc+8FX5kOzHrCrjVA5o7yQHQG_SH-M7AYg@mail.gmail.com> (raw)
In-Reply-To: <ZkVRi0lk9od3SqWp@casper.infradead.org>
On Wed, May 15, 2024 at 5:21 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> For those who couldn't read the text on the wiki page earlier:
>
> https://kernelnewbies.org/MatthewWilcox/Memdescs
> https://kernelnewbies.org/MatthewWilcox/FolioAlloc
> https://kernelnewbies.org/MatthewWilcox/BuddyAllocator
> https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
>
> That fourth page is freshly created as a result of the discussions in
> the room. I'll continue to refine these pages as my understanding of
> various issues improves.
>
I took a look again at folio->memcg_data.
We have three types of pointers that we can put in there:
(a) struct mem_cgroup pointer (no flags set, for anon & file folios).
(b) struct obj_cgroup pointer (MEMCG_DATA_KMEM set, for non-slab
accounted allocations).
(c) a vector of struct obj_cgroup pointers (MEMCG_DATA_OBJCGS set, for
slab allocations).
I believe we should be able to get rid of MEMCG_DATA_OBJCGS now and
use a struct obj_cgroup ** directly in struct slab. I see a few places
where we change struct slab to struct folio or vice versa, but I don't
think they miss with the memcg stuff.
The only exception I can find is print_page_owner_memcg(), where we
use this flag when printing the memcg of a page to print that it is a
slab page (and hence no memcg will be printed). I believe a PageSlab()
check may be racy, but I am not sure, and I don't know if we really
care.
Now for (a) and (b). I believe once struct folio only represents anon
and file folios (or if they have separate types), we should be able to
use a struct mem_cgroup pointer. This will take care of (a).
Things like PerCPU and PageTable fit into category (b) and will have a
struct obj_cgroup pointer. The problem is other category (b)
allocations that fit into Misc and do not have associated metadata.
These allocations should have an associated obj_cgroup pointer if they
are accounted, but as far as I can tell we have no place to store it
according to the current plan.
prev parent reply other threads:[~2024-05-16 2:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 0:21 Memdesc wiki pages Matthew Wilcox
2024-05-16 2:28 ` Yosry Ahmed [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJD7tkZt-hrnrexBwc+8FX5kOzHrCrjVA5o7yQHQG_SH-M7AYg@mail.gmail.com \
--to=yosryahmed@google.com \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).