From: "Michal Koutný" <mkoutny@suse.com> To: Vasily Averin <vvs@openvz.org> Cc: Roman Gushchin <roman.gushchin@linux.dev>, Vlastimil Babka <vbabka@suse.cz>, Shakeel Butt <shakeelb@google.com>, kernel@openvz.org, Florian Westphal <fw@strlen.de>, linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.com>, cgroups@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Tejun Heo <tj@kernel.org> Subject: Re: kernfs memcg accounting Date: Mon, 2 May 2022 23:22:09 +0200 [thread overview] Message-ID: <YnBLge4ZQNbbxufc@blackbook> (raw) In-Reply-To: <7509fa9f-9d15-2f29-cb2f-ac0e8d99a948@openvz.org> Hello. On Mon, May 02, 2022 at 10:37:49PM +0300, Vasily Averin <vvs@openvz.org> wrote: > I did not understand your statement. Could you please explain it in more details? Sure, let me expand my perhaps ambiguous and indefinite sentence. > I see that cgroup_mkdir()->cgroup_create() creates new kernfs node for new > sub-directory, and with my patch account memory of kernfs node to memcg > of current process. Indeed. The variants I'm comparing here are: a) charge to the creator's memcg, b) charge to the parent (memcg ancestor) of created cgroup. When struct mem_cgroup charging was introduced, there was a similar discussion [1]. I can see following aspects here: 1) absolute size of kernfs_objects, 2) practical difference between a) and b), 3) consistency with memcg, 4) v1 vs v2 behavior. Ad 1) -- normally, I'd treat this as negligible (~120B struct kernfs_node * there are ~10 of them per subsys * ~10 subsystems ~ 12 KB/cgroup). But I guess the point of this change are exploitative users where this doesn't hold [2], so absolute size is not so important. Ad 2) -- in the typical workloads, only top-level cgroup are created by some management entity and lower level are managed from within, i.e. there is little difference whom to charge the created objects. Ad 3) -- struct mem_cgroup objects are charged to their hierarchical parent, so that dying memcgs can be associated to a subtree which is where the reclaim can deal with it (in contrast with creator's cgroup). Now, if I'm looking correctly, the kernfs_node objects are not pinned by any residual state (subsystems kill_css()->css_clear_dir() synchronously from rmdir, cgroup itself may be RCU delayed). So the memcg argument remains purely for consistency (but no practical reason). Ad 4) -- the variant b) becomes slightly awkward when mkdir'ing a cgroup in a non-memcg hierarchy (bubbles up to root, despite creator in a non-root memcg). How do these reasonings align with your original intention of net devices accounting? (Are the creators of net devices inside the container?) > Do you think it is incorrect and new kernfs node should be accounted > to memcg of parent cgroup, as mem_cgroup_css_alloc()-> mem_cgroup_alloc() does? I don't think either variant is incorrect. I'd very much prefer the consistency with memcg behavior (variant a)) but as I've listed the arguments above, it seems such a consistency can't be easily justified. > Perhaps you mean that in this case kernfs should not be counted at all, > as almost all neighboring allocations do? No, I think it wouldn't help here [2]. (Or which neighboring allocations do you mean? There must be at least nr_cgroups of them.) (Of course, then there's the traditional performance argument, cgroup's kernfs_node object shouldn't be problematic but I can't judge others (sysfs) but that's nothing to prevent any form of kernfs_node accounting going forward in my eyes.) HTH, Michal [1] https://lore.kernel.org/all/20200729171039.GA22229@blackbody.suse.cz/ [2] Unless this could be constraint by something even bigger and accounted. But only struct mem_cgroup (recursively its percpu stats) comes to my mind.
WARNING: multiple messages have this Message-ID (diff)
From: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org> To: Vasily Averin <vvs-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> Cc: Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>, Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>, Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, kernel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Subject: Re: kernfs memcg accounting Date: Mon, 2 May 2022 23:22:09 +0200 [thread overview] Message-ID: <YnBLge4ZQNbbxufc@blackbook> (raw) In-Reply-To: <7509fa9f-9d15-2f29-cb2f-ac0e8d99a948-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> Hello. On Mon, May 02, 2022 at 10:37:49PM +0300, Vasily Averin <vvs-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote: > I did not understand your statement. Could you please explain it in more details? Sure, let me expand my perhaps ambiguous and indefinite sentence. > I see that cgroup_mkdir()->cgroup_create() creates new kernfs node for new > sub-directory, and with my patch account memory of kernfs node to memcg > of current process. Indeed. The variants I'm comparing here are: a) charge to the creator's memcg, b) charge to the parent (memcg ancestor) of created cgroup. When struct mem_cgroup charging was introduced, there was a similar discussion [1]. I can see following aspects here: 1) absolute size of kernfs_objects, 2) practical difference between a) and b), 3) consistency with memcg, 4) v1 vs v2 behavior. Ad 1) -- normally, I'd treat this as negligible (~120B struct kernfs_node * there are ~10 of them per subsys * ~10 subsystems ~ 12 KB/cgroup). But I guess the point of this change are exploitative users where this doesn't hold [2], so absolute size is not so important. Ad 2) -- in the typical workloads, only top-level cgroup are created by some management entity and lower level are managed from within, i.e. there is little difference whom to charge the created objects. Ad 3) -- struct mem_cgroup objects are charged to their hierarchical parent, so that dying memcgs can be associated to a subtree which is where the reclaim can deal with it (in contrast with creator's cgroup). Now, if I'm looking correctly, the kernfs_node objects are not pinned by any residual state (subsystems kill_css()->css_clear_dir() synchronously from rmdir, cgroup itself may be RCU delayed). So the memcg argument remains purely for consistency (but no practical reason). Ad 4) -- the variant b) becomes slightly awkward when mkdir'ing a cgroup in a non-memcg hierarchy (bubbles up to root, despite creator in a non-root memcg). How do these reasonings align with your original intention of net devices accounting? (Are the creators of net devices inside the container?) > Do you think it is incorrect and new kernfs node should be accounted > to memcg of parent cgroup, as mem_cgroup_css_alloc()-> mem_cgroup_alloc() does? I don't think either variant is incorrect. I'd very much prefer the consistency with memcg behavior (variant a)) but as I've listed the arguments above, it seems such a consistency can't be easily justified. > Perhaps you mean that in this case kernfs should not be counted at all, > as almost all neighboring allocations do? No, I think it wouldn't help here [2]. (Or which neighboring allocations do you mean? There must be at least nr_cgroups of them.) (Of course, then there's the traditional performance argument, cgroup's kernfs_node object shouldn't be problematic but I can't judge others (sysfs) but that's nothing to prevent any form of kernfs_node accounting going forward in my eyes.) HTH, Michal [1] https://lore.kernel.org/all/20200729171039.GA22229-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org/ [2] Unless this could be constraint by something even bigger and accounted. But only struct mem_cgroup (recursively its percpu stats) comes to my mind.
next prev parent reply other threads:[~2022-05-02 21:22 UTC|newest] Thread overview: 267+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-27 10:37 [PATCH] memcg: accounting for objects allocated for new netdevice Vasily Averin 2022-04-27 10:37 ` Vasily Averin 2022-04-27 14:01 ` Michal Koutný 2022-04-27 14:01 ` Michal Koutný 2022-04-27 16:52 ` Shakeel Butt 2022-04-27 16:52 ` Shakeel Butt 2022-04-27 22:35 ` Vasily Averin 2022-04-27 22:35 ` Vasily Averin 2022-05-02 12:15 ` [PATCH memcg v2] " Vasily Averin 2022-05-04 20:50 ` Luis Chamberlain 2022-05-04 20:50 ` Luis Chamberlain 2022-05-05 3:50 ` patchwork-bot+netdevbpf 2022-05-05 3:50 ` patchwork-bot+netdevbpf-DgEjT+Ai2ygdnm+yROfE0A 2022-05-11 2:51 ` Roman Gushchin 2022-05-11 2:51 ` Roman Gushchin 2022-05-02 19:37 ` kernfs memcg accounting Vasily Averin 2022-05-02 19:37 ` Vasily Averin 2022-05-02 21:22 ` Michal Koutný [this message] 2022-05-02 21:22 ` Michal Koutný 2022-05-04 9:00 ` Vasily Averin 2022-05-04 9:00 ` Vasily Averin 2022-05-04 14:10 ` Michal Koutný 2022-05-04 14:10 ` Michal Koutný 2022-05-04 21:16 ` Vasily Averin 2022-05-04 21:16 ` Vasily Averin 2022-05-05 9:47 ` Michal Koutný 2022-05-05 9:47 ` Michal Koutný 2022-05-06 8:37 ` Vasily Averin 2022-05-06 8:37 ` Vasily Averin 2022-05-11 3:06 ` Roman Gushchin 2022-05-11 3:06 ` Roman Gushchin 2022-05-11 6:01 ` Vasily Averin 2022-05-11 6:01 ` Vasily Averin 2022-05-11 16:49 ` Michal Koutný 2022-05-11 16:49 ` Michal Koutný 2022-05-11 17:46 ` Roman Gushchin 2022-05-11 17:46 ` Roman Gushchin 2022-05-11 16:34 ` Michal Koutný 2022-05-11 16:34 ` Michal Koutný 2022-05-11 18:10 ` Roman Gushchin 2022-05-11 18:10 ` Roman Gushchin 2022-05-13 15:51 ` [PATCH 0/4] memcg: accounting for objects allocated by mkdir cgroup Vasily Averin 2022-05-13 15:51 ` Vasily Averin 2022-05-13 17:49 ` Roman Gushchin 2022-05-13 17:49 ` Roman Gushchin 2022-05-21 16:37 ` [PATCH mm v2 0/9] " Vasily Averin 2022-05-21 16:37 ` Vasily Averin 2022-05-30 11:25 ` [PATCH mm v3 " Vasily Averin 2022-05-30 11:25 ` Vasily Averin 2022-05-30 11:55 ` Michal Hocko 2022-05-30 11:55 ` Michal Hocko 2022-05-30 13:09 ` Vasily Averin 2022-05-30 13:09 ` Vasily Averin 2022-05-30 14:22 ` Michal Hocko 2022-05-30 14:22 ` Michal Hocko 2022-05-30 19:58 ` Vasily Averin 2022-05-30 19:58 ` Vasily Averin 2022-05-31 7:16 ` Michal Hocko 2022-05-31 7:16 ` Michal Hocko 2022-06-01 3:43 ` Vasily Averin 2022-06-01 3:43 ` Vasily Averin 2022-06-01 9:15 ` Michal Koutný 2022-06-01 9:15 ` Michal Koutný 2022-06-01 9:32 ` Michal Hocko 2022-06-01 9:32 ` Michal Hocko 2022-06-01 13:05 ` Michal Hocko 2022-06-01 13:05 ` Michal Hocko 2022-06-01 14:22 ` Roman Gushchin 2022-06-01 14:22 ` Roman Gushchin 2022-06-01 15:24 ` Michal Hocko 2022-06-01 15:24 ` Michal Hocko 2022-06-01 9:26 ` Michal Hocko 2022-06-13 5:34 ` [PATCH mm v4 " Vasily Averin 2022-06-13 5:34 ` Vasily Averin 2022-06-23 14:50 ` [PATCH mm v5 0/9] memcg: accounting for objects allocated by mkdir, cgroup Vasily Averin 2022-06-23 14:50 ` Vasily Averin 2022-06-23 15:03 ` Vasily Averin 2022-06-23 15:03 ` Vasily Averin 2022-06-23 16:07 ` Michal Hocko 2022-06-23 16:07 ` Michal Hocko 2022-06-23 16:55 ` Shakeel Butt 2022-06-23 16:55 ` Shakeel Butt 2022-06-24 10:40 ` Vasily Averin 2022-06-24 10:40 ` Vasily Averin 2022-06-24 12:26 ` Michal Koutný 2022-06-24 12:26 ` Michal Koutný 2022-06-24 13:59 ` Michal Hocko 2022-06-24 13:59 ` Michal Hocko 2022-06-25 9:43 ` [PATCH RFC] memcg: avoid idr ids space depletion Vasily Averin 2022-06-25 9:43 ` Vasily Averin 2022-06-25 14:04 ` [PATCH RFC] memcg: notify about global mem_cgroup_id " Vasily Averin 2022-06-25 14:04 ` Vasily Averin 2022-06-26 1:56 ` Roman Gushchin 2022-06-26 1:56 ` Roman Gushchin 2022-06-26 7:11 ` Vasily Averin 2022-06-26 7:11 ` Vasily Averin 2022-06-27 2:12 ` [PATCH cgroup] cgroup: set the correct return code if hierarchy limits are reached Vasily Averin 2022-06-27 2:12 ` Vasily Averin 2022-06-27 3:33 ` Muchun Song 2022-06-27 3:33 ` Muchun Song 2022-06-27 9:07 ` Tejun Heo 2022-06-27 9:07 ` Tejun Heo 2022-06-28 0:44 ` Roman Gushchin 2022-06-28 0:44 ` Roman Gushchin 2022-06-28 3:59 ` Vasily Averin 2022-06-28 3:59 ` Vasily Averin 2022-06-28 9:16 ` Michal Koutný 2022-06-28 9:16 ` Michal Koutný 2022-06-28 9:22 ` Tejun Heo 2022-06-29 6:13 ` Vasily Averin 2022-06-29 6:13 ` Vasily Averin 2022-06-29 19:25 ` Tejun Heo 2022-06-29 19:25 ` Tejun Heo 2022-07-01 2:42 ` Roman Gushchin 2022-07-01 2:42 ` Roman Gushchin 2022-06-27 2:11 ` [PATCH mm v2] memcg: notify about global mem_cgroup_id space depletion Vasily Averin 2022-06-27 3:23 ` Muchun Song 2022-06-27 3:23 ` Muchun Song 2022-06-27 6:49 ` Vasily Averin 2022-06-27 6:49 ` Vasily Averin 2022-06-28 1:11 ` Roman Gushchin 2022-06-28 1:11 ` Roman Gushchin 2022-06-28 3:43 ` Vasily Averin 2022-06-28 3:43 ` Vasily Averin 2022-06-28 9:08 ` Michal Koutný 2022-06-28 9:08 ` Michal Koutný 2022-06-27 16:37 ` [PATCH mm v5 0/9] memcg: accounting for objects allocated by mkdir, cgroup Shakeel Butt 2022-06-27 16:37 ` Shakeel Butt 2022-07-01 11:03 ` Michal Hocko 2022-07-10 18:53 ` Vasily Averin 2022-07-10 18:53 ` Vasily Averin 2022-07-11 16:24 ` Michal Hocko 2022-07-11 16:24 ` Michal Hocko 2022-06-23 14:50 ` [PATCH mm v5 1/9] memcg: enable accounting for struct cgroup Vasily Averin 2022-06-23 14:50 ` Vasily Averin 2022-06-23 14:50 ` [PATCH mm v5 2/9] memcg: enable accounting for kernfs nodes Vasily Averin 2022-06-23 14:50 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 3/9] memcg: enable accounting for kernfs iattrs Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 4/9] memcg: enable accounting for struct simple_xattr Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 5/9] memcg: enable accounting for percpu allocation of struct psi_group_cpu Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 6/9] memcg: enable accounting for percpu allocation of struct cgroup_rstat_cpu Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 7/9] memcg: enable accounting for large allocations in mem_cgroup_css_alloc Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:51 ` [PATCH mm v5 8/9] memcg: enable accounting for allocations in alloc_fair_sched_group Vasily Averin 2022-06-23 14:51 ` Vasily Averin 2022-06-23 14:52 ` [PATCH mm v5 9/9] memcg: enable accounting for perpu allocation of struct rt_rq Vasily Averin 2022-06-23 14:52 ` Vasily Averin 2022-06-13 5:34 ` [PATCH mm v4 1/9] memcg: enable accounting for struct cgroup Vasily Averin 2022-06-13 5:34 ` Vasily Averin 2022-06-13 5:34 ` [PATCH mm v4 2/9] memcg: enable accounting for kernfs nodes Vasily Averin 2022-06-13 5:34 ` Vasily Averin 2022-06-13 5:34 ` [PATCH mm v4 3/9] memcg: enable accounting for kernfs iattrs Vasily Averin 2022-06-13 5:34 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 4/9] memcg: enable accounting for struct simple_xattr Vasily Averin 2022-06-13 5:35 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 5/9] memcg: enable accounting for percpu allocation of struct psi_group_cpu Vasily Averin 2022-06-13 5:35 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 6/9] memcg: enable accounting for percpu allocation of struct cgroup_rstat_cpu Vasily Averin 2022-06-13 5:35 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 7/9] memcg: enable accounting for large allocations in mem_cgroup_css_alloc Vasily Averin 2022-06-13 5:35 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 8/9] memcg: enable accounting for allocations in alloc_fair_sched_group Vasily Averin 2022-06-13 5:35 ` Vasily Averin 2022-06-13 5:35 ` [PATCH mm v4 9/9] memcg: enable accounting for perpu allocation of struct rt_rq Vasily Averin [not found] ` <cover.1653899364.git.vvs@openvz.org> 2022-05-30 11:25 ` [PATCH mm v3 1/9] memcg: enable accounting for struct cgroup Vasily Averin 2022-05-30 11:25 ` Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 2/9] memcg: enable accounting for kernfs nodes Vasily Averin 2022-05-30 11:26 ` Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 3/9] memcg: enable accounting for kernfs iattrs Vasily Averin 2022-05-30 11:26 ` Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 4/9] memcg: enable accounting for struct simple_xattr Vasily Averin 2022-05-30 11:26 ` Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 5/9] memcg: enable accounting for percpu allocation of struct psi_group_cpu Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 6/9] memcg: enable accounting for percpu allocation of struct cgroup_rstat_cpu Vasily Averin 2022-05-30 15:04 ` Muchun Song 2022-05-30 15:04 ` Muchun Song 2022-05-30 11:26 ` [PATCH mm v3 7/9] memcg: enable accounting for large allocations in mem_cgroup_css_alloc Vasily Averin 2022-05-30 11:26 ` Vasily Averin 2022-05-30 11:26 ` [PATCH mm v3 8/9] memcg: enable accounting for allocations in alloc_fair_sched_group Vasily Averin 2022-05-30 11:26 ` Vasily Averin 2022-05-30 11:27 ` [PATCH mm v3 9/9] memcg: enable accounting for perpu allocation of struct rt_rq Vasily Averin 2022-05-30 11:27 ` Vasily Averin 2022-05-30 15:06 ` Muchun Song 2022-05-21 16:37 ` [PATCH mm v2 1/9] memcg: enable accounting for struct cgroup Vasily Averin 2022-05-21 16:37 ` Vasily Averin 2022-05-22 6:37 ` Muchun Song 2022-05-22 6:37 ` Muchun Song 2022-05-21 16:37 ` [PATCH mm v2 2/9] memcg: enable accounting for kernfs nodes Vasily Averin 2022-05-21 16:37 ` Vasily Averin 2022-05-22 6:37 ` Muchun Song 2022-05-22 6:37 ` Muchun Song 2022-05-21 16:37 ` [PATCH mm v2 3/9] memcg: enable accounting for kernfs iattrs Vasily Averin 2022-05-21 16:37 ` Vasily Averin 2022-05-22 6:38 ` Muchun Song 2022-05-22 6:38 ` Muchun Song 2022-05-21 16:38 ` [PATCH mm v2 4/9] memcg: enable accounting for struct simple_xattr Vasily Averin 2022-05-21 16:38 ` Vasily Averin 2022-05-22 6:38 ` Muchun Song 2022-05-22 6:38 ` Muchun Song 2022-05-21 16:38 ` [PATCH mm v2 5/9] memcg: enable accounting for percpu allocation of struct psi_group_cpu Vasily Averin 2022-05-21 16:38 ` Vasily Averin 2022-05-21 21:34 ` Shakeel Butt 2022-05-21 21:34 ` Shakeel Butt 2022-05-22 6:40 ` Muchun Song 2022-05-22 6:40 ` Muchun Song 2022-05-25 1:30 ` Roman Gushchin 2022-05-25 1:30 ` Roman Gushchin 2022-05-21 16:38 ` [PATCH mm v2 6/9] memcg: enable accounting for percpu allocation of struct cgroup_rstat_cpu Vasily Averin 2022-05-21 16:38 ` Vasily Averin 2022-05-21 17:58 ` Vasily Averin 2022-05-21 17:58 ` Vasily Averin 2022-05-21 21:35 ` Shakeel Butt 2022-05-21 21:35 ` Shakeel Butt 2022-05-21 22:05 ` kernel test robot 2022-05-21 22:05 ` kernel test robot 2022-05-25 1:31 ` Roman Gushchin 2022-05-25 1:31 ` Roman Gushchin 2022-05-21 16:38 ` [PATCH mm v2 7/9] memcg: enable accounting for large allocations in mem_cgroup_css_alloc Vasily Averin 2022-05-21 16:38 ` Vasily Averin 2022-05-22 6:47 ` Muchun Song 2022-05-22 6:47 ` Muchun Song 2022-05-21 16:38 ` [PATCH mm v2 8/9] memcg: enable accounting for allocations in alloc_fair_sched_group Vasily Averin 2022-05-21 16:38 ` Vasily Averin 2022-05-22 6:49 ` Muchun Song 2022-05-21 16:39 ` [PATCH mm v2 9/9] memcg: enable accounting for percpu allocation of struct rt_rq Vasily Averin 2022-05-21 16:39 ` Vasily Averin 2022-05-21 21:37 ` Shakeel Butt 2022-05-21 21:37 ` Shakeel Butt 2022-05-25 1:31 ` Roman Gushchin 2022-05-25 1:31 ` Roman Gushchin 2022-05-13 15:51 ` [PATCH 1/4] memcg: enable accounting for large allocations in mem_cgroup_css_alloc Vasily Averin 2022-05-13 15:51 ` Vasily Averin 2022-05-19 16:46 ` Michal Koutný 2022-05-19 16:46 ` Michal Koutný 2022-05-20 1:07 ` Shakeel Butt 2022-05-20 1:07 ` Shakeel Butt 2022-05-13 15:51 ` [PATCH 2/4] memcg: enable accounting for kernfs nodes and iattrs Vasily Averin 2022-05-13 15:51 ` Vasily Averin 2022-05-19 16:33 ` Michal Koutný 2022-05-19 16:33 ` Michal Koutný 2022-05-20 1:12 ` Shakeel Butt 2022-05-20 1:12 ` Shakeel Butt 2022-05-13 15:52 ` [PATCH 3/4] memcg: enable accounting for struct cgroup Vasily Averin 2022-05-13 15:52 ` Vasily Averin 2022-05-19 16:53 ` Michal Koutný 2022-05-19 16:53 ` Michal Koutný 2022-05-20 7:24 ` Vasily Averin 2022-05-20 7:24 ` Vasily Averin 2022-05-20 20:16 ` Vasily Averin 2022-05-20 20:16 ` Vasily Averin 2022-05-21 0:55 ` Roman Gushchin 2022-05-21 0:55 ` Roman Gushchin 2022-05-21 7:28 ` Vasily Averin 2022-05-21 7:28 ` Vasily Averin 2022-05-23 13:52 ` Michal Koutný 2022-05-23 13:52 ` Michal Koutný 2022-05-20 1:31 ` Shakeel Butt 2022-05-13 15:52 ` [PATCH 4/4] memcg: enable accounting for allocations in alloc_fair_sched_group Vasily Averin 2022-05-13 15:52 ` Vasily Averin 2022-05-19 16:45 ` Michal Koutný 2022-05-19 16:45 ` Michal Koutný 2022-05-20 1:18 ` Shakeel Butt 2022-05-20 1:18 ` Shakeel Butt
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=YnBLge4ZQNbbxufc@blackbook \ --to=mkoutny@suse.com \ --cc=cgroups@vger.kernel.org \ --cc=fw@strlen.de \ --cc=gregkh@linuxfoundation.org \ --cc=kernel@openvz.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mhocko@suse.com \ --cc=roman.gushchin@linux.dev \ --cc=shakeelb@google.com \ --cc=tj@kernel.org \ --cc=vbabka@suse.cz \ --cc=vvs@openvz.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.