linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option
@ 2024-05-09  3:41 Roman Gushchin
  2024-05-09  3:41 ` [PATCH rfc 1/9] mm: memcg: introduce memcontrol-v1.c Roman Gushchin
                   ` (11 more replies)
  0 siblings, 12 replies; 32+ messages in thread
From: Roman Gushchin @ 2024-05-09  3:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Muchun Song, Johannes Weiner, Michal Hocko, Shakeel Butt,
	Matthew Wilcox, linux-mm, linux-kernel, Roman Gushchin

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



^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2024-05-28 17:20 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-09  3:41 [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option Roman Gushchin
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox