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 90D10C25B74 for ; Thu, 16 May 2024 03:36:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0659B6B0397; Wed, 15 May 2024 23:36:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 012256B039D; Wed, 15 May 2024 23:36:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF4D86B03A0; Wed, 15 May 2024 23:36:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B8F006B0397 for ; Wed, 15 May 2024 23:36:37 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 201278108A for ; Thu, 16 May 2024 03:36:37 +0000 (UTC) X-FDA: 82122846834.14.435A391 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf17.hostedemail.com (Postfix) with ESMTP id 43E1640013 for ; Thu, 16 May 2024 03:36:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gTx2khbt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715830595; 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=JWc8JJQxlxGEETOHoMDodWpK/v1HjwSNgwsdZCmzeV0=; b=FMsCmirilyFOnKFghJxZjJhOZNo1wHkkbJLiPla6cVsnS7a71azvCquttPfb9sL0Vu9c9x EpkUYIMU8Hq5YTBjpxzmWc2XLT3fR2velCxnOGrErLA2qrBK2Ef3N3oNONzhQ4QdjmqLuH y3g8nCxy4fhZKVDaCGAPLmMl74mH3To= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gTx2khbt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715830595; a=rsa-sha256; cv=none; b=cHhMWLmtIhyX/CW552rpPciP5RzryL52Uy9z85iI3ivCLyF2AsC5UvlIbMLjXFRtQz1sIu TrA/51iV3Rwjbrjiy/0gAtJpzwpChgiuWWE8uaDjO5th8c+nKHHYB6LXL/Z2aM9w/1Flz8 77PGN/2b7BAssqA8pLXZqp0otX0vWdg= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-43e385a7589so5151201cf.3 for ; Wed, 15 May 2024 20:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715830594; x=1716435394; 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=JWc8JJQxlxGEETOHoMDodWpK/v1HjwSNgwsdZCmzeV0=; b=gTx2khbt1Aqq1hiA8NNd2Ls54gGN11JniAoPybtOsRsxw5GAjXXWkKr4fKU0hM2akE YWgmlfPQyP+O5zDVaT3XMDpzgdutPo8v60Jw5tgKK1AZoi5fscU22KMn4RzbFjRv+zeo IOzuru+2jaOVirIjuRcGdS6SFJ8V+mn+xxFLvzKhG/FA+mingLjP84z/jwyu5nHvhm6C o/7ANQuOAacJBRMs1OdJyMieyUL9K2wLSp9iQKfr2wLtUpsCTkLbBiB1gBSwOrbWQYYV 3gzDRanUGC7aszKoRqgoh8QCR312/N4ZqqcAqa65Kye2Zxa5elx9+YF7Q236sncQ0hW7 7d+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715830594; x=1716435394; 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=JWc8JJQxlxGEETOHoMDodWpK/v1HjwSNgwsdZCmzeV0=; b=GoPP4eC6fVcUcDYXkpMcvuqNEnlu1OR1WoG674M1+LzQV+jPy6yHjSZAZZMpQthtg4 Gi6CtkCWz9UaU7NVtDU3ustWY2p2vM7hygkENIvJZf10ROeWnATF62LZPRBREVsWBLlr drb2d2/iczhI1wrfjp/CZ49Svpqw2vArTsDWH6d+2ve77U2WGrR8WA8W77zNwTxbBo9s JOgXGcB4tYAmVEvX2BUyVdq5uombUxsOwXN7mac9HI0dbexm/DKv5JGKbHcqSvX6gv+B 0OEMRu8d6feu9qJ8Sds6WcWjWeoaxt5lOL63fFonr47DurOJ00HGCzpoBAGhHkzYHSqG nAGw== X-Forwarded-Encrypted: i=1; AJvYcCVqLMlRfSwclrvJ8QDhK78mMLJhAL3FtM8OhWPIdaegvr1KnedSFZ3MqHqzvB/ICbTKTv3qNGpIhWdS42zlB0jqCBQ= X-Gm-Message-State: AOJu0YxfW9LvOJXIME3DLwmw0vjAn6T6t5PQY4caV2Rt+bj41OvNXnMQ MnsTfrjelIgEwzxCLi4lQduvjVTvT41z1dXTfgNmwLHUcR3U8M9rrAFxyZV09bFhnKFYXI48jZ5 syGHElj5pKP/qBl5iiFMFXhKutio= X-Google-Smtp-Source: AGHT+IHWOwFNDVSCskdy4Caj7SrKTUmz/j6xyhyvlFvAIJH32D+C3DzVnIl2uW9iwMKW8KwonaWTOxkRCPZK4xUq/oQ= X-Received: by 2002:a05:6214:5a07:b0:6a0:d3ef:2a7e with SMTP id 6a1803df08f44-6a16825bd31mr246840826d6.61.1715830594239; Wed, 15 May 2024 20:36:34 -0700 (PDT) MIME-Version: 1.0 References: <20240509034138.2207186-1-roman.gushchin@linux.dev> In-Reply-To: From: Yafang Shao Date: Thu, 16 May 2024 11:35:57 +0800 Message-ID: Subject: Re: [PATCH rfc 0/9] mm: memcg: separate legacy cgroup v1 code and put under config option To: Shakeel Butt , Yosry Ahmed 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 43E1640013 X-Stat-Signature: mc4xz7y7geqtzf6n9ddzrc8ixskru94o X-HE-Tag: 1715830595-579967 X-HE-Meta: U2FsdGVkX184q1IldQMf3bFvZ9IuoXhSD5xbqJznkmSzZLLz5oofCMIgt4mmfWmU2AcRULkESgxG+jZPgMaWBdzbjr2C0Td8TQ0mbf6DQZ6wkQKge7ofeX+/P9eEIKQ6shL+Q+JdRyt0TbwEtdDuA/MSdA0OfUY8Iu8N/jiJVtr5S2q2aUT98SD3gaOBviIqPjvUHZVSVlYyrEvWX4b0b4VE6R6+QUC/5/fi6GnoWQ1/TqDAMhebM6KIIicssOsvMKIdhs1+IjAVkVKS9g2IlZLZ0/u5bKWmIDphSX9o2YRXqhasNKH5V97zN9Xq0b5b3hG/kmS5qKGi0r73qGIAliuXxFRzpMjhxxvoblEQBXrPl9CC9/AXw/vL3vh1V4MSFZoDAHe+UbiAZm+2mKSdIk+615EjoM6CRMEgjAXvT5twf4yJgEnySsZIgmKn3py0M4l67kNrixgeVEkN3fw5/WFaaf069rGkm7mNltVp59gfNL/19DRe2k0HfQhAlSFj5bQaY/Ozkna3NJBfPaLHz1vR49N9lgayogWmDnGmoRKplQhr1AG4tUbeNcOBXy5b/m3PkX7B7wY1+OYguS4+erlOm4zWsL+LQzQn9gsEJDHsEHNl836oeSzJkUf/dn+NPuL40tWVgJ7FQB9jwLy9N2Qpm3JCaEs7nKdcPKUzMGKB3s4QOc3Zi9qNfVu+FZHOsi8A9VCRxtkKxM6rSxY6XOVL3uQEr6QdJuCyuvwwbMvooIYAct5Rs+0172vwBQCGjQ3fNQMt9DXsgW/B6BR2IV+FUs01EJl8LFInhcP9KPIdixtUjbrXov64jbomLhGF/JV5eD7BUXLR9yDFyynFZCs4QDSvBbpUmzqIIXkBgd6xfq2eb1SFVjqOtUFVvUIukbGu0eG2Guhqzjx/wPzgpEhDJXSjenRLyFO/O/IfdqfToxcJcUFFZp/MzlcoMc5+1mIGXe71jwWS6HsoL6K a3DTXoos lYqfRi0rpOZm+8GEv6gM+EnG2x+HBGCwjdCgW0fyKepGEekfMbYLS9c3LDK6585mWOGGNsMaw9+KEI9RDzE/QbSML42NlzTs7S9Iyt0q9onJOWWkEevctIZfYMIX1QbeR7xaZbPDgjn1Xv8AIzSPA5QWXWd+cvKjq/bD2iQ+hJacXtjlSPYd7BUoV0GUwknIPLGgnCpVgpEsaE6O+pAssFgI0pgQca5u1Mk6G4sgs9RJbi0I2ef3AMEsFIjRzRMJV7dwW8fz7RM4J5/TqpM1NO2D3Q5GZhIy2jyTvRcTeYqLoSowmOxeDAc8XSTOisugEBm9wOa56e9vDu+F6drdvLVcjFM+DrZP+Xobte65qE/5ay6ky0Y59XJO4hr03h/Y/VLY3 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 Shakeel, Hopefully I'm not too late. We are currently using memcg v1. One specific feature we rely on in v1 is skmem accounting. In v1, we account for TCP memory usage without charging it to memcg v1, which is useful for monitoring the TCP memory usage generated by tasks running in a container. However, in memcg v2, monitoring TCP memory requires charging it to the container, which can easily cause OOM issues. It would be better if we could monitor skmem usage without charging it in the memcg v2, allowing us to account for it without the risk of triggering OOM conditions. --=20 Regards Yafang