From: Roman Gushchin <firstname.lastname@example.org> To: Shakeel Butt <email@example.com> Cc: "Michal Koutný" <firstname.lastname@example.org>, "Johannes Weiner" <email@example.com>, "Richard Palethorpe" <firstname.lastname@example.org>, "LTP List" <email@example.com>, "Andrew Morton" <firstname.lastname@example.org>, "Christoph Lameter" <email@example.com>, "Michal Hocko" <firstname.lastname@example.org>, "Tejun Heo" <email@example.com>, "Vlastimil Babka" <firstname.lastname@example.org>, "Linux MM" <email@example.com>, LKML <firstname.lastname@example.org>, "Michal Hocko" <email@example.com> Subject: Re: [RFC PATCH] mm: memcg/slab: Stop reparented obj_cgroups from charging root Date: Tue, 20 Oct 2020 10:17:14 -0700 Message-ID: <20201020171714.GB153102@carbon.DHCP.thefacebook.com> (raw) In-Reply-To: <CALvZod66ETQR2rKhZQfEZwdovuF0AaVTZ1g1JNjkLgLGgMKY8g@mail.gmail.com> On Tue, Oct 20, 2020 at 09:55:38AM -0700, Shakeel Butt wrote: > On Mon, Oct 19, 2020 at 3:28 PM Roman Gushchin <firstname.lastname@example.org> wrote: > > > > On Fri, Oct 16, 2020 at 07:15:02PM +0200, Michal Koutny wrote: > > > On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner <email@example.com> wrote: > > > > The central try_charge() function charges recursively all the way up > > > > to and including the root. > > > Except for use_hiearchy=0 (which is the case here as Richard > > > wrote). The reparenting is hence somewhat incompatible with > > > new_parent.use_hiearchy=0 :-/ > > > > > > > We should clean this up one way or another: either charge the root or > > > > don't, but do it consistently. > > > I agree this'd be good to unify. One upside of excluding root memcg from > > > charging is that users are spared from the charging overhead when memcg > > > tree is not created. (Actually, I thought that was the reason for this > > > exception.) > > > > Yeah, I'm completely on the same page. Moving a process to the root memory > > cgroup is currently a good way to estimate the memory cgroup overhead. > > > > How about the patch below, which consistently avoids charging the root > > memory cgroup? It seems like it doesn't add too many checks. > > > > Thanks! > > > > -- > > > > From f50ea74d8f118b9121da3754acdde630ddc060a7 Mon Sep 17 00:00:00 2001 > > From: Roman Gushchin <firstname.lastname@example.org> > > Date: Mon, 19 Oct 2020 14:37:35 -0700 > > Subject: [PATCH RFC] mm: memcontrol: do not charge the root memory cgroup > > > > Currently the root memory cgroup is never charged directly, but > > if an ancestor cgroup is charged, the charge is propagated up to the > > root memory cgroup. The root memory cgroup doesn't show the charge > > to a user, neither it does allow to set any limits/protections. > > So the information about the current charge is completely useless. > > > > Avoiding to charge the root memory cgroup allows to: > > 1) simplify the model and the code, so, hopefully, fewer bugs will > > be introduced in the future; > > 2) avoid unnecessary atomic operations, which are used to (un)charge > > corresponding root page counters. > > > > In the default hierarchy case or if use_hiearchy == true, it's very > > straightforward: when the page counters tree is traversed to the root, > > the root page counter (the one with parent == NULL), should be > > skipped. To avoid multiple identical checks over the page counters > > code, for_each_nonroot_ancestor() macro is introduced. > > > > To handle the use_hierarchy == false case without adding custom > > checks, let's make page counters of all non-root memory cgroup > > direct ascendants of the corresponding root memory cgroup's page > > counters. In this case for_each_nonroot_ancestor() will work correctly > > as well. > > > > Please, note, that cgroup v1 provides root level memory.usage_in_bytes. > > However, it's not based on page counters (refer to mem_cgroup_usage()). > > > > Signed-off-by: Roman Gushchin <email@example.com> > > This patch is only doing the page counter part of the cleanup (i.e. to > not update root's page counters when descendent's page counter is > updated) but not the stats part. > > For the user memory, we do update the stats for the root memcg and do > set page->mem_cgroup = root_mem_cgroup. However this is not done for > the kmem/obj. I thought this is what Johannes was asking for the > cleanup. Yes, it's not the whole story, of course. Actually I missed that we do export root kmem and tcpmem counters on cgroup v1 (thanks Michal to pointing at it!). If we want them to function properly, we have to go into the opposite direction and start charging the root cgroup for all kinds of kernel memory allocations. We also have the same problem with root MEMCG_SOCK stats, which seems to be broken now. I'll master a patch. Thanks!
prev parent reply index Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-14 19:07 Richard Palethorpe 2020-10-14 20:08 ` Roman Gushchin 2020-10-16 5:40 ` Richard Palethorpe 2020-10-16 9:47 ` Michal Koutný 2020-10-16 10:41 ` Richard Palethorpe 2020-10-16 15:05 ` Richard Palethorpe 2020-10-16 17:26 ` Michal Koutný 2020-10-16 14:53 ` Johannes Weiner 2020-10-16 17:02 ` Roman Gushchin 2020-10-16 17:15 ` Michal Koutný 2020-10-19 8:45 ` Richard Palethorpe 2020-10-19 9:58 ` [PATCH v3] " Richard Palethorpe 2020-10-19 16:58 ` Shakeel Butt 2020-10-20 5:52 ` Richard Palethorpe 2020-10-20 13:49 ` Richard Palethorpe 2020-10-20 16:56 ` Shakeel Butt 2020-10-21 20:32 ` Roman Gushchin 2020-10-20 17:24 ` Michal Koutný 2020-10-22 7:04 ` Richard Palethorpe 2020-10-22 12:28 ` [PATCH v4] " Richard Palethorpe 2020-10-22 16:37 ` Shakeel Butt 2020-10-22 17:25 ` Roman Gushchin 2020-10-22 23:59 ` Shakeel Butt 2020-10-23 0:40 ` Roman Gushchin 2020-10-23 15:44 ` Johannes Weiner 2020-10-23 16:41 ` Shakeel Butt 2020-10-26 7:32 ` Richard Palethorpe 2020-10-26 23:14 ` Roman Gushchin 2020-10-19 22:28 ` [RFC PATCH] " Roman Gushchin 2020-10-20 6:04 ` Richard Palethorpe 2020-10-20 12:02 ` Richard Palethorpe 2020-10-20 14:48 ` Richard Palethorpe 2020-10-20 16:27 ` Michal Koutný 2020-10-20 17:07 ` Roman Gushchin 2020-10-20 18:18 ` Johannes Weiner 2020-10-21 19:33 ` Roman Gushchin 2020-10-23 16:30 ` Johannes Weiner 2020-11-10 1:27 ` Roman Gushchin 2020-11-10 15:11 ` Shakeel Butt 2020-11-10 19:13 ` Roman Gushchin 2020-11-20 17:46 ` Michal Koutný 2020-11-03 13:22 ` Michal Hocko 2020-11-03 21:30 ` Roman Gushchin 2020-10-20 16:55 ` Shakeel Butt 2020-10-20 17:17 ` Roman Gushchin [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=20201020171714.GB153102@carbon.DHCP.thefacebook.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ firstname.lastname@example.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git