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 5837EC25B10 for ; Fri, 10 May 2024 07:11:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E37236B0083; Fri, 10 May 2024 03:11:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE67C6B0087; Fri, 10 May 2024 03:11:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD6886B0088; Fri, 10 May 2024 03:11:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B00F96B0083 for ; Fri, 10 May 2024 03:11:14 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5EB911417A2 for ; Fri, 10 May 2024 07:11:14 +0000 (UTC) X-FDA: 82101614868.05.E4B63AB Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id BD19212000D for ; Fri, 10 May 2024 07:11:11 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fc8ZH+SQ; spf=pass (imf29.hostedemail.com: domain of chrisl@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715325072; 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=uSDPOFZMBtE0jEK4V0BRpEm5DCDPQotJmApYGjORHp8=; b=v4uu+ivKC5LDMj72g1YFH4Sjgu/xiTdPIRLoPVgf+IV/xDkPiVTFfDomL35ILH/BNwDrOj G0BivFJRoBVsoiMOATF7C3B6G8UfrccR+hdKFPZwdAA//jhuLY4Nung6JghL1Dw19JpaHC bkkEGFpUxZsHVNnnPELDhM5wa4zExKU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fc8ZH+SQ; spf=pass (imf29.hostedemail.com: domain of chrisl@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715325072; a=rsa-sha256; cv=none; b=P9uka1acwatrik6FCobmzqzAa4Q0ukWU6ZiSekAzDSfNOwH8+3NHKdeimnIa/z+kGpkex0 bjoIRSD+sr0I/hzZh52GJr8tQyiyR5KQn449l3asJLW6+eLH7BPGCO+xWLMPWkN+u5n1kA H0K9yrt987tRK4GRxhsQWuafHsybjTc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 19CF4CE1C29 for ; Fri, 10 May 2024 07:11:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7A8CC32786 for ; Fri, 10 May 2024 07:11:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715325066; bh=Z9ApargRseOze0lK8nAdGp6lAx3o/KGDjDeb4qiKKMg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fc8ZH+SQsgdJVx0arRPTSzS8k9BzelNIFR6Fl+f0sIlZv8Zrf0VwCEntmkBty1ijd JKlUxuHh0uMzN/jmr5DC8urZdNthfEPeUJJP/To2HRGR8A/3q0elOufGSR93FZ1oDE 3215IsTYvZ7Rc9RuvaJtuXkV6j9tAleuXqsA20StgN5R5UJyOFgzgOYhyBUSO2nrWJ 0nkyxeM073NEOWedWyuU9M5R24oYoPjkhVZAW0L/wv9YTGy8QM1m2hNkwA/gvbf5yU jCtd70dxGd+68KI1QuC+7W5b9h6qhlrtPn9qxPts/jRb0rSU06lxbBZi6VUFi+Iakq ipzea0SE6ER5A== Received: by mail-il1-f170.google.com with SMTP id e9e14a558f8ab-36c5eedd124so7242305ab.2 for ; Fri, 10 May 2024 00:11:06 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWVuXkp46V2rNB2bC0qAQ2oZnocaVhv2TrnOexFgJC5tKUbQNZ9hiYgHG/60j91bJMjhH9iZSWqtJBDyJ+Ts57uASY= X-Gm-Message-State: AOJu0YzTJtFCwHYm//QRytWh83a87qfMPkBaUhbbHkI21Q15Cobcp/J3 lvFwQGOido5AAzc6ed47E6pwD0ftwK1RcxGsvYkPJ7hVg5BFA2ValVdXgsJU44GNt2HELHWzsaJ EqAT6OWFZZcm4ygFmtBXQaFtTGjv6z7CDpCU1 X-Google-Smtp-Source: AGHT+IG1x0iEXhiDjKzCvD3azTG3/Qn0LkuU9YYEsZbRyOeqsBhhwiMjUdwYX5Ga7VuaUTtqX3k5b2AUsfl/5xfGC8s= X-Received: by 2002:a05:6e02:1c88:b0:36c:84e0:252d with SMTP id e9e14a558f8ab-36cc1501b7fmr21479035ab.27.1715325066029; Fri, 10 May 2024 00:11:06 -0700 (PDT) MIME-Version: 1.0 References: <20240509034138.2207186-1-roman.gushchin@linux.dev> In-Reply-To: From: Chris Li Date: Fri, 10 May 2024 00:10:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option To: David Rientjes Cc: Shakeel Butt , Roman Gushchin , Andrew Morton , Muchun Song , Johannes Weiner , Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, gthelen@google.coma Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 5it89xm7tckg4bxd9tbb15w3utujcpcu X-Rspam-User: X-Rspamd-Queue-Id: BD19212000D X-Rspamd-Server: rspam05 X-HE-Tag: 1715325071-585486 X-HE-Meta: U2FsdGVkX188eq7iEDzjNfurAPRoXNleNum9vHgXZf60box1ZBka4K8JXdjppCJkDxMSN+IOTwC41X0WXckGSjSbKbNAvtB3ic73hK4wywq9Anwj3fpjkBmu4v8ZG6tEWqTeKTjn5GS07jHeD+GsMTuZ8f1lwTxXZc0CJzXz6eLShXIQLpjApAcq0Yw0VnntQ2YGHi8Gyp+gY8UrdWqtsliMq9EL78cH/fGB9BnfBs3r1WYQ/K+Z40kcx93EJo2uLEmef8nQiDGNxlYjPfw2dXTshHce33yQM0YC+rZhpRLa4vUnqu0sRfTS4Swo9wY0C5tXdQ7AYzeIQGO8EOC9OW3jgTRKYnXexc1XjSnOSMUFWvpNmsVrkKHKhBeD5bnjJXxxnfJ9nY7t5rm8Qn1W2Y0BQxkESytRHFM8yNJPHrvnJBMinTpqqRzGfUs4xY08NawjXbRj8iT1wi5qW1mGG8EDqXm6xlVeOFWOw4JPQiokJnwEZGdSnrQ5ZZRQt4HcIjQaZU4mmJi44pMa3qq80rz3UN8FLzdMDl3hWY+/ozJA2DbaTfTTfeEfS/acEMWhVZ3g8TYkmGJ/uAFSByivEXO2QjriPEfq14iuRlWx0omSjKCzoR7Jh7H2XS/8xdzMmzwDmyB0x0mlrUF5keklGAjUq9V34qKR27FS9nl4p+XiYSeV63W6fzVjK6A2DZcSZHH+54Ad0oSbqQqWR6+znNHnzXQTGDOq1nGbavjfAquyjgVHidgosIVCl+Xaj8R/sLox+WXP5KzEvNqG7EknBFIPJTFbVCKzD5vkYPvpWL6+fG1e+3/2LvJm1uGRJa0WVSwR+lUPHDCfiX5lvkeLqJIuS8x2CHcBrU6JVEL6Y7sr6zoJC81eO5OLsP7NXzxIpqCv9snbcSaxB3QFSZ4I5MtKGG0xPKg2PHTr+/jMrl/58JmSu3R4D3VV735lqzpsI+wli0rMuNT5WY54CAp HgZPd+zy 799McCWa5E08hi2xMZP775LOXkN9f7TfEICTwcZdpNwwA4QCF2l67dMGRa9j4PXP9u+liZHRl60eWLdD9NsywXUqg+uiVd37I9f13vsLB8KoRdFba80ny1l6rbcxzuktNgLTXZ2H3tba4r2vul8JnJf1hW9KU0Ph6+lQ85GdOtAz8J8FhpQchq5QET21G0MaBT7iAcm1nsEgEgvfuNEuMbUGlxNVHHpCz6O+SVj6DEDYOx1t8c7YvyG/SWtIiolf02tLyjbR55UasC6aTtqjyDq9nEcc6Dbx3aMzpotOH+QSnuW4= 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 7:59=E2=80=AFPM David Rientjes = wrote: > > On Wed, 8 May 2024, Shakeel Butt wrote: > > > Hi Roman, > > > > A very timely and important topic and we should definitely talk about i= t > > 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. > > > > I think this would be a very worthwhile discussion at LSF/MM, I'm not sur= e > if it would be too late for someone to make a formal proposal for it to b= e > included in the schedule. Michal would know if there is a opportunity. > > I say that in light of > https://lore.kernel.org/bpf/ZjL5b-zipMrV2JSg@archie.me/T/#mb6c21b09543c43= 4dd85e718a8ecf5ca6485e6d07 > as well for the whole cgroup v1 -> v2 transition. > > Chris, now cc'd, would know best about all of the dependencies that Googl= e > has for memcg specifically. Thanks David, Yes, I am very interested in that cgroup v1 -> v2 transition discussion. > > > 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) In the list mentioned by Roman: "soft limit reclaim, oom handling in usersp= ace, complicated event notification system, charge migration." The "oom.control" and leak of user space oom control is a big one for googl= e. Some test frameworks also use "memory.force_empty". Soft limit reclaim and charge migration is also used. There is also the combined "memsw" limit enforcement. Google has some internal work around for V2 but it would be good if that upstream can support it directly. BTW, I know you are not looking for the "cgroup v2 structure restrictions". Two cgroup controllers that can't have different sets of processes is a bit too restrictive. That is what I recall right now, I might be missing some small odd items. Anyway, glad to join the discussion if there is a session. Chris Chris > > > > 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" situatio= n > > 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. > > > > thanks, > > Shakeel > >