From mboxrd@z Thu Jan 1 00:00:00 1970 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 E1C8BC25B79 for ; Wed, 22 May 2024 17:59:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C1496B0085; Wed, 22 May 2024 13:59:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36FEC6B0088; Wed, 22 May 2024 13:59:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 237FA6B0089; Wed, 22 May 2024 13:59:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 024ED6B0085 for ; Wed, 22 May 2024 13:59:09 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id ADF9F1C4D5D for ; Wed, 22 May 2024 17:59:09 +0000 (UTC) X-FDA: 82146793218.05.80281BC Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf30.hostedemail.com (Postfix) with ESMTP id C2FB880018 for ; Wed, 22 May 2024 17:59:07 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e+WU9H32; spf=pass (imf30.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716400747; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TkY2zCKj0rH560r132+SkB6lM4KVc9auRQua4/wMef4=; b=kNse8MgyKV3oviXe68FnNre2i4NcwzsL60+1+eOu+27m6hBZaSViZmuItFejUZ5+kuAvOq UyWKb1dn5VrCcGRivU7fNCuMZZr7F/4VYm4nFJ8OsDOViWrOkDMuvtBMTU2m9p/sNRhHrI F32Xn6GE1ClQ53NFdv86cfd/puFrIls= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e+WU9H32; spf=pass (imf30.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716400747; a=rsa-sha256; cv=none; b=jf5//BGeGF9BG5J4KoJVqwO05Gb6kf9j1QKve2p4C8t3ODjr4CdGVwOkPoj0M/0PpmRPfX dXb1lylFKV1AcwVxi4mXH7gvIodkyDEyWR1lo0MtT/9WnzJDkpfWvc2QI2PMW/81qqk17o J4Qm263tGr4V6OU2dWOEclr/rmAMDi0= Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2e564cad1f1so75149931fa.0 for ; Wed, 22 May 2024 10:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716400746; x=1717005546; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TkY2zCKj0rH560r132+SkB6lM4KVc9auRQua4/wMef4=; b=e+WU9H327CocrfO3tBIyc78xcuK2Ky63qrwTRY7bK1c7POuizBKNNylUdT/vcUBccl lik41z9VC2rYL+R9T0iLwzlwE2JDNLRO/khbV6zmCS+KFsSJN40V/7/oFE5gQ+aL+7pF kK8Fwj4DDV4DcBF17fxaTglAtUU62nfaWxwLLDF7oq2zPXlNdBpz3k6eHHaNixKBfpOE dcuUM/aPjZ3gpaYJUPBWHYgjLi4ExE4QnT/+ZwCb056wPj3N8PpkapJGWQjnw6PuD5hz NDPFKLc78oZ7HV4fWrkwd+U+TAJ7KFD8TXaRFctMEsi4kPEfGZkS1iLhxQl6wrXDkn9b x37g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716400746; x=1717005546; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TkY2zCKj0rH560r132+SkB6lM4KVc9auRQua4/wMef4=; b=vNoEOlwlSriY/BPWxApddD5Ba1C7ZKzVOdVdvSSEA1BOpZEjNFQryomdX5JQkTuvKG 59rzTiZChPvpC/l57EkprZn9rinHXbGomCKMOcidj486mfxqXR6b2oh9KPoKWdMI5ZHJ i664M2MqQBchDwcD+nAmBcfIf0GvpmXdvNIj1aIgd55hl2x+VOE1Jpq8jnalhKHbI00E A3M2RFNmuvFioigMg8wSPnO9W+yCuJ7jZdinN/bKcaDcmEmEgQY2sZ6IWq21ME3nSoMF PfNd3XR178uat0anOhJyiFmGdNXYR97B0DjmWOMRv+T4112IRXEgoCvyQOoPD4MPpP41 xnEA== X-Forwarded-Encrypted: i=1; AJvYcCU4H1t3WTwtNgKRFnDK7nextcL+0dwnP5fJjr1z6AJiRC2ozfNQrgvHxo8A0l61PG2klJjZhl70aSWNmvfUYo1XhfM= X-Gm-Message-State: AOJu0YzgsHRTLmRiGiSMqG1jqCDP4QZU811dqlxRUcgwKQrGfWNQdRXY CCCXX0bchvZ2QrK+5nPD7Te/JPJibVNn0nvfzhiBpNaokRL0+YKnG8tWBpQ2dwkti6q6NdnCK+B mHNsKx5jZfiAvJqXY1SxrcD609eQ= X-Google-Smtp-Source: AGHT+IGp6atU+fl+TD0KSvFFSZu3dqO1SHwmise3SbvYgZ7eIk4FgRYkgFDVVUfHepH47yUMfDgV/D5f88YVVCMnTHY= X-Received: by 2002:a2e:b043:0:b0:2e5:685a:cd24 with SMTP id 38308e7fff4ca-2e949583e90mr16371131fa.6.1716400745826; Wed, 22 May 2024 10:59:05 -0700 (PDT) MIME-Version: 1.0 References: <20240509034138.2207186-1-roman.gushchin@linux.dev> In-Reply-To: From: Kairui Song Date: Thu, 23 May 2024 01:58:49 +0800 Message-ID: Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option To: Shakeel Butt Cc: Roman Gushchin , Andrew Morton , Muchun Song , Johannes Weiner , Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, gthelen@google.coma, rientjes@google.com, Chris Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C2FB880018 X-Stat-Signature: 5dfhf4gchy94x4rf9wnexzfawowhzpkk X-HE-Tag: 1716400747-913423 X-HE-Meta: U2FsdGVkX18oJ0mwD9nXD5LydLJnm4lB6YCf0IwSS4GQ4HrKvDNhm2wd4clPr65ah1Mg25VAJsmK3b53iS7XHY3cPRZHAXZevchHomKwK9ct0BBg4F8/z20fUYOUHAsfloCrowDZcpx1XjCN+tteQnQIGIqtuoE7PXTNqCMgvrL+68cFUsYCW1u4s0rA6+lb9VeCoMbHvUWNW5GShC9at57fiqOjWGSDr/vy7vBhF3c/4n+p6u0l0bxCdOipyvEgLsGrhH58d5KlqS2gKl84KTZHeVAU9McjAMGgzzWeet0rzuMFASRV7qTIdZFGk7rXge8TJkzoylVq4g42v5Q7i7MgsatV8NjBm15MuyQYYxPXYo9n5Fd7SxaPFOHlNVmeFK+RWI0YUWUh+vQBGkE2FX+pc4ra4Cp/ZGdmqCE786BgEBRU+qkxLVgjNhAi+TTWFVbPaNGSsMKPjeCtZoPlMoGaMwQx5GLNF98qRYKy75l25YQPVTBioceeZdTc0DoY5PRylV4rm2XqiGlNfE04gPWIu1/k9YUxzRl6n2G8stwmhM4rqEyscV2uf2g4HussDhA0MbdcXdHk9XUx6wc96k/x/mKyCVUl6IpK65/zO9ycBVkX2F1bubKRfTuYmBm78DIJLjgcRwEJeov+yWNGispOySn8ayFS6RpEG/JBLe5oXMkgdwgbdfJnfgpd76Iyl45w0/ZsoQoeX5zQsEiKu/vQzR33rm2eyO4FgSxO8uUyo97KQFmhCSikvN1G5W+VgkkewU0tTnsmn9uB5bxcbfPIxEKGOUaA0s5/aMJ3JwPOdjuqCJa+TbOfXVu11b81qeyLTM0u8y+qqD4UJmS/iRkMgZ7N+cNPu3Jt6rYQktz3jpJULEhTPFi5SoJ+G/tRdoZzLNtN2MlCpHcKS2R5XVkUmj/Y6dRC6t7c8oOx9XeiBeg8bB1JpzYi4+Cx8IKwJpFsv7n3lBpdBOLxAC8 xvupKtXj yU6+aYPU0Ov2ZZ4aWEWeoa9oDfewGK9ikcH2B27dA2+VG6guE3WIoBznqdlirgq/m7J5lev95xeenfGtyp39ccwK3Y/wVnLeKqVELbSynm5molYzT9pOE6w1byXIYUWOaSQUvTRpd+dSkee+536zHbmyZm+oguGWQ9eJrCuLEkH8jgtnI4K0bWTX8zWSGIIVaDCVSR5mx3+gIk481Q6HQUdA/yzFk342ujbQLMMgrQ6hlUWE3SPBw3ADFx9k/JkPVctLkVK5UJhIXTqIwb0Ne4OUGlIzw/ayjzlAj2SnD/gKYSy565+XQCzJ1Yx8aBFFWjPT0oHAcF2G/15ynMH+dvchrpBFdoGggU/IC 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: On Thu, May 9, 2024 at 2:33=E2=80=AFPM Shakeel Butt wrote: > > On Wed, May 08, 2024 at 08:41:29PM -0700, Roman Gushchin wrote: > > Cgroups v2 have been around for a while and many users have fully adopt= ed 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 us= ed > > 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 sup= ported > > by cgroup v2 and their implementation is pretty much self contained. > > Most notably, these features are: soft limit reclaim, oom handling in u= serspace, > > complicated event notification system, charge migration. > > > > Cgroup v1-specific code in memcontrol.c is close to 4k lines in size an= d 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 f= ile, > > 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. > > > > Hi Roman, > > A very timely and important topic and we should definitely talk about it > during LSFMM as well. I have been thinking about this problem for quite > sometime and I am getting more and more convinced that we should aim to > completely deprecate memcg-v1. > > More specifically: > > 1. What are the memcg-v1 features which have no alternative in memcg-v2 > and are blocker for memcg-v1 users? (setting aside the cgroup v2 > structual restrictions) > > 2. What are unused memcg-v1 features which we should start deprecating? > > IMO we should systematically start deprecating memcg-v1 features and > start unblocking the users stuck on memcg-v1. > > Now regarding the proposal in this series, I think it can be a first > step but should not give an impression that we are done. The only > concern I have is the potential of "out of sight, out of mind" situation > with this change but if we keep the momentum of deprecation of memcg-v1 > it should be fine. > > I have CCed Greg and David from Google to get their opinion on what > memcg-v1 features are blocker for their memcg-v2 migration and if they > have concern in deprecation of memcg-v1 features. > > Anyone else still on memcg-v1, please do provide your input. > Hi, Sorry for joining the discussion late, but I'd like to add some info here: We are using the "memsw" feature a lot. It's a very useful knob for container memory overcommitting: It's a great abstraction of the "expected total memory usage" of a container, so containers can't allocate too much memory using SWAP, but still be able to SWAP out. For a simple example, with memsw.limit =3D=3D memory.limit, containers can't exceed their original memory limit, even with SWAP enabled, they get OOM killed as how they used to, but the host is now able to offload cold pages. Similar ability seems absent with V2: With memory.swap.max =3D=3D 0, the host can't use SWAP to reclaim container memory at all. But with a value larger than that, containers are able to overuse memory, causing delayed OOM kill, thrashing, CPU/Memory usage ratio could be heavily out of balance, especially with compress SWAP backends. Cgroup accounting of ZSWAP/ZRAM doesn't really help, we want to account for the total raw usage, not the compressed usage. One example is that if a container uses tons of duplicated pages, then it can allocate much more memory than it is limited, that could cause trouble. I saw Chris also mentioned Google has a workaround internally for it for Cgroup V2. This will be a blocker for us and a similar workaround might be needed. It will be great so see an upstream support for this.