From patchwork Thu May 9 03:41:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roman Gushchin X-Patchwork-Id: 13659410 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0A59C25B75 for ; Thu, 9 May 2024 03:42:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60B546B0083; Wed, 8 May 2024 23:42:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E2A86B0088; Wed, 8 May 2024 23:42:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 374316B0092; Wed, 8 May 2024 23:42:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0E00E6B0083 for ; Wed, 8 May 2024 23:42:17 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A0982141295 for ; Thu, 9 May 2024 03:42:16 +0000 (UTC) X-FDA: 82097459472.21.D83A51C Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf24.hostedemail.com (Postfix) with ESMTP id 6137B18000C for ; Thu, 9 May 2024 03:42:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KM41Ypk5; spf=pass (imf24.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715226135; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=aOzHyI83zs0yARPQLHmu0dTTl11iaaEJdBLCPGzT9nI=; b=1pZUURJXHVChGbXmP/KQkseUhGBDQSnOib/nbQysQaswOWt2FP1juizT7RTigB8otmaF5g fq9GT5sxOHO/ep1uFlAovNNeGqmHutkdkvKIggwsbAJ10MqWCOBlHq6HXT0AEhvsH5CS78 90XVoER79ei0v7q1oxzkdxUXQiZ3cuo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KM41Ypk5; spf=pass (imf24.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715226135; a=rsa-sha256; cv=none; b=UOps0en8jttCmSwkxxIjydJR8A4dbGGvMA8FeI8E1QvAX5LjjNBSlxcWZv8QPLsxrrPUBw hRKFHf2iG+VCsHAZmyNdyGsjBt/U1oFf7sukya1QGW9owBB+FtwwZlUSfZjS1dEBSaChCH MitavF9lfcCKEOrHNpZAMlNTFq7ileQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1715226129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=aOzHyI83zs0yARPQLHmu0dTTl11iaaEJdBLCPGzT9nI=; b=KM41Ypk56xmIB122yjsznS4X6hO16Qd+qsnf4bwOZeuvVrKwEwDLJ3SconmZf2FldpLZSB BHe11kAOakOuo9xdlUbOT2ZII3yA1hMSaW5bov1mlcx3/+0QtqedtW34sd+BSuo1DWYLCK qgw0pfiOtL9HL99kJhZ2U+8iRUhqaw8= From: Roman Gushchin To: Andrew Morton Cc: Muchun Song , Johannes Weiner , Michal Hocko , Shakeel Butt , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Roman Gushchin 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 Message-ID: <20240509034138.2207186-1-roman.gushchin@linux.dev> MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Stat-Signature: fjn4d8553wix7ot94zrk9jg9rojh9mc1 X-Rspamd-Queue-Id: 6137B18000C X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1715226133-633609 X-HE-Meta: U2FsdGVkX184+9uDUO7U3q6azu/57vaTWDaBfkTsJrx3ksfaIEiWjt+LoTzDSAcaqf2l5qVpoSsfzrkyYPQDLerJtRHGmILGDM6t2IhyGZl/SKu9ByRsWtkTugKEzUX4tbfFh3vJMMCeKo1LzM2aov8gXHpTRcGDEp5w/gFRJkjMZTwSCqrohJbVA69J0E5kQE8lMsq1Lkbtswx+tksP1khOth0+iUD0mr9Uk15w4GMs1XOYJofSJFOM2oCUAh3cfXIhaO+pm7WErNBbhoMQPgWSJvPI68TlYKpVFRwk/5B4gYfY2sKCOVz5GZNkoLa4Kypa7F6NpK3EJiDp4Gjfes2YHwArakNtF9SxF8s98BxSXah7cBi4IPwvqDOJ9xXTho68N5Yeevj+DYKv3iEr3/saT7QsoqrxX/3Z2tx+M6TtiEckzCWksn6CM2yQWtdZfk5zp6LMh26X8oysG/Vv5WWCr5ZD9qwjqGJuXWqUz7uxOQBWStSvIvbX8F9NAK9x4kgQMYpK9BybwC0D9aK7RzdF7D01yXYdlh/z6sQMwEeVyMgjU3fZ2RB6PIJ/YwmJxfss9/EuFL+nKK2viH/M7zLgPjS3yGEek5gUyBlx1Wm51cnRQUi1zkT1e1F8yS0rrZ3P5B1e/lEzHUlxQ01REgntwEGY2zmDZ+U4SmTuGrqrz4bLkERLZECRA9lBzQq4GBukEZcbG3QdU3GBGcAiNcfjjMPfGbhBeBQ3dK3NXAbehC/w2IiGBKR43baMptsydDpt6/AhgWPaEHOgzijsBrjKdPieLbSb09P6nscx8mloHkPP3m8V2Ptd4pGsaPiPW0/WSJEY6SSMQRBc474EdtdfGiuRVMv63AhPkMID3f+MzBxE9S5S6rSzq5SAWvBRTy6lcI6J9V9KAb1D40zjr41SgwvLHoSnbn5au2yvfiPMQziMnSmUBE7l9f50mfnwVMi5phpN+S0GvWWNAu4 J9wuYvYo bKcjxVCY4Zn/oMgCq8MVzRoDVMpkTKuM2xQMe1pqYgNK/UoqwdX14BIkZk3bXnD+xYnO2shf8+csHlFNhUzGOND3sMMqRoNpsiPB8rkuq/iB07MKyYLD/chm0WrZvG3f9T5EMRJxDkJme5LA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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) Signed-off-by: Roman Gushchin 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