From: Johannes Weiner <hannes@cmpxchg.org> To: Waiman Long <llong@redhat.com> Cc: Michal Hocko <mhocko@kernel.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Vlastimil Babka <vbabka@suse.cz>, Roman Gushchin <guro@fb.com>, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt <shakeelb@google.com>, Muchun Song <songmuchun@bytedance.com>, Alex Shi <alex.shi@linux.alibaba.com>, Chris Down <chris@chrisdown.name>, Yafang Shao <laoar.shao@gmail.com>, Wei Yang <richard.weiyang@gmail.com>, Masayoshi Mizuma <msys.mizuma@gmail.com>, Xing Zhengjun <zhengjun.xing@linux.intel.com>, Matthew Wilcox <willy@infradead.org> Subject: Re: [PATCH v4 1/5] mm/memcg: Move mod_objcg_state() to memcontrol.c Date: Mon, 19 Apr 2021 17:11:37 -0400 [thread overview] Message-ID: <YH3yCZn9EeSPKKGY@cmpxchg.org> (raw) In-Reply-To: <d1c36f26-b958-49e0-ae44-1cf6334fa4c5@redhat.com> On Mon, Apr 19, 2021 at 01:26:29PM -0400, Waiman Long wrote: > On 4/19/21 1:19 PM, Waiman Long wrote: > > On 4/19/21 1:13 PM, Johannes Weiner wrote: > > > The CONFIG_MEMCG_KMEM has become sort of useless now. It used to be > > > configurable, but now it just means CONFIG_MEMCG && !CONFIG_SLOB. And > > > even that doesn't make sense because while slob doesn't support slab > > > object tracking, we can still do all the other stuff we do under > > > KMEM. I have a patch in the works to remove the symbol and ifdefs. > > > > > > With that in mind, it's better to group the functions based on what > > > they do rather than based on CONFIG_MEMCG_KMEM. It's easier to just > > > remove another ifdef later than it is to reorder the functions. > > > > > OK, I will make the move then. Thanks for the explanation. Thanks! > BTW, have you ever thought of moving the cgroup-v1 specific functions out > into a separate memcontrol-v1.c file just like kernel/cgroup/cgroup-v1.c? > > I thought of that before, but memcontrol.c is a frequently changed file and > so a bit hard to do. I haven't looked too deeply at it so far, but I think it would make sense to try. There are indeed many of the entry paths from the MM code that are shared between cgroup1 and cgroup2, with smaller branches here and there to adjust behavior. Those would throw conflicts, but those we should probably keep in the main memcontrol.c for readability anyway. But there is also plenty of code that is exclusively about cgroup1, and which actually doesn't change much in a long time. Moving that elsewhere shouldn't create difficult conflicts - maybe a few line offset warnings or fuzz in the diff context of unrelated changes: - the soft limit tree and soft limit reclaim - the threshold and oom event notification stuff - the charge moving code - remaining v1 interface files, as well as their helper functions From a quick scan, this adds up to ~2,500 lines of old code with no actual dependencies from the common code or from v2, and which could be moved out of the way without disrupting ongoing development much.
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> To: Waiman Long <llong-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Vladimir Davydov <vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>, Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Joonsoo Kim <iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org>, Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Muchun Song <songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>, Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>, Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>, Yafang Shao <laoar.shao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Wei Yang <richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Masayoshi Mizuma <msys.mizuma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Xing Zhengjun <zhengjun.xing-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, Matthew Wilcox <> Subject: Re: [PATCH v4 1/5] mm/memcg: Move mod_objcg_state() to memcontrol.c Date: Mon, 19 Apr 2021 17:11:37 -0400 [thread overview] Message-ID: <YH3yCZn9EeSPKKGY@cmpxchg.org> (raw) In-Reply-To: <d1c36f26-b958-49e0-ae44-1cf6334fa4c5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> On Mon, Apr 19, 2021 at 01:26:29PM -0400, Waiman Long wrote: > On 4/19/21 1:19 PM, Waiman Long wrote: > > On 4/19/21 1:13 PM, Johannes Weiner wrote: > > > The CONFIG_MEMCG_KMEM has become sort of useless now. It used to be > > > configurable, but now it just means CONFIG_MEMCG && !CONFIG_SLOB. And > > > even that doesn't make sense because while slob doesn't support slab > > > object tracking, we can still do all the other stuff we do under > > > KMEM. I have a patch in the works to remove the symbol and ifdefs. > > > > > > With that in mind, it's better to group the functions based on what > > > they do rather than based on CONFIG_MEMCG_KMEM. It's easier to just > > > remove another ifdef later than it is to reorder the functions. > > > > > OK, I will make the move then. Thanks for the explanation. Thanks! > BTW, have you ever thought of moving the cgroup-v1 specific functions out > into a separate memcontrol-v1.c file just like kernel/cgroup/cgroup-v1.c? > > I thought of that before, but memcontrol.c is a frequently changed file and > so a bit hard to do. I haven't looked too deeply at it so far, but I think it would make sense to try. There are indeed many of the entry paths from the MM code that are shared between cgroup1 and cgroup2, with smaller branches here and there to adjust behavior. Those would throw conflicts, but those we should probably keep in the main memcontrol.c for readability anyway. But there is also plenty of code that is exclusively about cgroup1, and which actually doesn't change much in a long time. Moving that elsewhere shouldn't create difficult conflicts - maybe a few line offset warnings or fuzz in the diff context of unrelated changes: - the soft limit tree and soft limit reclaim - the threshold and oom event notification stuff - the charge moving code - remaining v1 interface files, as well as their helper functions From a quick scan, this adds up to ~2,500 lines of old code with no actual dependencies from the common code or from v2, and which could be moved out of the way without disrupting ongoing development much.
next prev parent reply other threads:[~2021-04-19 21:11 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-19 0:00 [PATCH v4 0/5] mm/memcg: Reduce kmemcache memory accounting overhead Waiman Long 2021-04-19 0:00 ` Waiman Long 2021-04-19 0:00 ` [PATCH v4 1/5] mm/memcg: Move mod_objcg_state() to memcontrol.c Waiman Long 2021-04-19 0:00 ` Waiman Long 2021-04-19 15:14 ` Johannes Weiner 2021-04-19 15:14 ` Johannes Weiner 2021-04-19 15:21 ` Waiman Long 2021-04-19 15:21 ` Waiman Long 2021-04-19 16:18 ` Waiman Long 2021-04-19 16:18 ` Waiman Long 2021-04-19 17:13 ` Johannes Weiner 2021-04-19 17:13 ` Johannes Weiner 2021-04-19 17:19 ` Waiman Long 2021-04-19 17:19 ` Waiman Long 2021-04-19 17:26 ` Waiman Long 2021-04-19 17:26 ` Waiman Long 2021-04-19 21:11 ` Johannes Weiner [this message] 2021-04-19 21:11 ` Johannes Weiner 2021-04-19 21:24 ` Waiman Long 2021-04-19 21:24 ` Waiman Long 2021-04-20 8:05 ` Michal Hocko 2021-04-20 8:05 ` Michal Hocko 2021-04-19 15:24 ` Shakeel Butt 2021-04-19 15:24 ` Shakeel Butt 2021-04-19 15:24 ` Shakeel Butt 2021-04-19 0:00 ` [PATCH v4 2/5] mm/memcg: Cache vmstat data in percpu memcg_stock_pcp Waiman Long 2021-04-19 16:38 ` Johannes Weiner 2021-04-19 16:38 ` Johannes Weiner 2021-04-19 23:42 ` Waiman Long 2021-04-19 23:42 ` Waiman Long 2021-04-19 0:00 ` [PATCH v4 3/5] mm/memcg: Optimize user context object stock access Waiman Long 2021-04-19 0:00 ` [PATCH v4 4/5] mm/memcg: Save both reclaimable & unreclaimable bytes in object stock Waiman Long 2021-04-19 0:00 ` Waiman Long 2021-04-19 16:55 ` Johannes Weiner 2021-04-19 16:55 ` Johannes Weiner 2021-04-20 19:09 ` Waiman Long 2021-04-20 19:09 ` Waiman Long 2021-04-19 0:00 ` [PATCH v4 5/5] mm/memcg: Improve refill_obj_stock() performance Waiman Long 2021-04-19 0:00 ` Waiman Long 2021-04-19 6:06 ` [External] " Muchun Song 2021-04-19 6:06 ` Muchun Song 2021-04-19 6:06 ` Muchun Song 2021-04-19 15:00 ` Shakeel Butt 2021-04-19 15:00 ` Shakeel Butt 2021-04-19 15:00 ` Shakeel Butt 2021-04-19 15:19 ` Waiman Long 2021-04-19 15:19 ` Waiman Long 2021-04-19 15:56 ` Waiman Long 2021-04-19 15:56 ` Waiman Long
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=YH3yCZn9EeSPKKGY@cmpxchg.org \ --to=hannes@cmpxchg.org \ --cc=akpm@linux-foundation.org \ --cc=alex.shi@linux.alibaba.com \ --cc=cgroups@vger.kernel.org \ --cc=chris@chrisdown.name \ --cc=cl@linux.com \ --cc=guro@fb.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=laoar.shao@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=llong@redhat.com \ --cc=mhocko@kernel.org \ --cc=msys.mizuma@gmail.com \ --cc=penberg@kernel.org \ --cc=richard.weiyang@gmail.com \ --cc=rientjes@google.com \ --cc=shakeelb@google.com \ --cc=songmuchun@bytedance.com \ --cc=tj@kernel.org \ --cc=vbabka@suse.cz \ --cc=vdavydov.dev@gmail.com \ --cc=willy@infradead.org \ --cc=zhengjun.xing@linux.intel.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: 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.