From: Roman Gushchin <roman.gushchin@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Muchun Song <muchun.song@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roman Gushchin <roman.gushchin@linux.dev>
Subject: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option
Date: Wed, 8 May 2024 20:41:29 -0700 [thread overview]
Message-ID: <20240509034138.2207186-1-roman.gushchin@linux.dev> (raw)
Cgroups v2 have been around for a while and many users have fully adopted them,
so they never use cgroups v1 features and functionality. Yet they have to "pay"
for the cgroup v1 support anyway:
1) the kernel binary contains useless cgroup v1 code,
2) some common structures like task_struct and mem_cgroup have never used
cgroup v1-specific members,
3) some code paths have additional checks which are not needed.
Cgroup v1's memory controller has a number of features that are not supported
by cgroup v2 and their implementation is pretty much self contained.
Most notably, these features are: soft limit reclaim, oom handling in userspace,
complicated event notification system, charge migration.
Cgroup v1-specific code in memcontrol.c is close to 4k lines in size and it's
intervened with generic and cgroup v2-specific code. It's a burden on
developers and maintainers.
This patchset aims to solve these problems by:
1) moving cgroup v1-specific memcg code to the new mm/memcontrol-v1.c file,
2) putting definitions shared by memcontrol.c and memcontrol-v1.c into the
mm/internal.h header
3) introducing the CONFIG_MEMCG_V1 config option, turned on by default
4) making memcontrol-v1.c to compile only if CONFIG_MEMCG_V1 is set
5) putting unused struct memory_cgroup and task_struct members under
CONFIG_MEMCG_V1 as well.
This is an RFC version, which is not 100% polished yet, so but it would be great
to discuss and agree on the overall approach.
Some open questions, opinions are appreciated:
1) I consider renaming non-static functions in memcontrol-v1.c to have
mem_cgroup_v1_ prefix. Is this a good idea?
2) Do we want to extend it beyond the memory controller? Should
3) Is it better to use a new include/linux/memcontrol-v1.h instead of
mm/internal.h? Or mm/memcontrol-v1.h.
diffstat:
include/linux/memcontrol.h | 165 ++++---
include/linux/sched.h | 5 +-
init/Kconfig | 7 +
mm/Makefile | 2 +
mm/internal.h | 124 +++++
mm/memcontrol-v1.c | 2941 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mm/memcontrol.c | 4121 ++++++++++++++++++++++---------------------------------------------------------------------------------------------------------------------------------
7 files changed, 3765 insertions(+), 3600 deletions(-)
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
Roman Gushchin (9):
mm: memcg: introduce memcontrol-v1.c
mm: memcg: move soft limit reclaim code to memcontrol-v1.c
mm: memcg: move charge migration code to memcontrol-v1.c
mm: memcg: move legacy memcg event code into memcontrol-v1.c
mm: memcg: move cgroup v1 interface files to memcontrol-v1.c
mm: memcg: move cgroup v1 oom handling code into memcontrol-v1.c
mm: memcg: put cgroup v1-specific code under a config option
mm: memcg: put corresponding struct mem_cgroup members under
CONFIG_MEMCG_V1
mm: memcg: put cgroup v1-related members of task_struct under config
option
include/linux/memcontrol.h | 165 +-
include/linux/sched.h | 5 +-
init/Kconfig | 7 +
mm/Makefile | 2 +
mm/internal.h | 124 ++
mm/memcontrol-v1.c | 2941 +++++++++++++++++++++++++
mm/memcontrol.c | 4121 ++++++------------------------------
7 files changed, 3765 insertions(+), 3600 deletions(-)
create mode 100644 mm/memcontrol-v1.c
--
2.43.2
next reply other threads:[~2024-05-09 3:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 3:41 Roman Gushchin [this message]
2024-05-09 3:41 ` [PATCH rfc 1/9] mm: memcg: introduce memcontrol-v1.c Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 2/9] mm: memcg: move soft limit reclaim code to memcontrol-v1.c Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 3/9] mm: memcg: move charge migration " Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 4/9] mm: memcg: move legacy memcg event code into memcontrol-v1.c Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 5/9] mm: memcg: move cgroup v1 interface files to memcontrol-v1.c Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 6/9] mm: memcg: move cgroup v1 oom handling code into memcontrol-v1.c Roman Gushchin
2024-05-10 13:26 ` Michal Hocko
2024-05-25 1:03 ` Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 7/9] mm: memcg: put cgroup v1-specific code under a config option Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 8/9] mm: memcg: put corresponding struct mem_cgroup members under CONFIG_MEMCG_V1 Roman Gushchin
2024-05-09 3:41 ` [PATCH rfc 9/9] mm: memcg: put cgroup v1-related members of task_struct under config option Roman Gushchin
2024-05-09 6:33 ` [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put " Shakeel Butt
2024-05-09 17:30 ` Roman Gushchin
2024-05-10 2:59 ` David Rientjes
2024-05-10 7:10 ` Chris Li
2024-05-10 8:10 ` Michal Hocko
2024-05-16 3:35 ` Yafang Shao
2024-05-16 17:29 ` Roman Gushchin
2024-05-17 2:21 ` Yafang Shao
2024-05-18 2:13 ` Roman Gushchin
2024-05-18 7:32 ` Shakeel Butt
2024-05-20 2:14 ` Yafang Shao
2024-05-22 17:58 ` Kairui Song
2024-05-23 19:55 ` Roman Gushchin
2024-05-23 20:26 ` Chris Li
2024-05-28 17:20 ` Kairui Song
2024-05-09 14:22 ` Johannes Weiner
2024-05-09 14:36 ` Johannes Weiner
2024-05-09 14:57 ` Roman Gushchin
2024-05-10 14:18 ` Johannes Weiner
2024-05-10 13:33 ` Michal Hocko
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=20240509034138.2207186-1-roman.gushchin@linux.dev \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=shakeel.butt@linux.dev \
--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