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 840AEC02196 for ; Thu, 6 Feb 2025 04:56:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CBA26B0082; Wed, 5 Feb 2025 23:56:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17C9C6B0085; Wed, 5 Feb 2025 23:56:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01B606B008A; Wed, 5 Feb 2025 23:56:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D55846B0082 for ; Wed, 5 Feb 2025 23:56:24 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 902121C85A0 for ; Thu, 6 Feb 2025 04:56:24 +0000 (UTC) X-FDA: 83088308688.26.6CF1334 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 9D517180002 for ; Thu, 6 Feb 2025 04:56:22 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="L5H/r30y"; spf=pass (imf24.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 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=1738817782; 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=553hF+T7BWF2LLgAhHz451B5EJreka9CG49KJHF3jzI=; b=pAEfbvS2o9C41174EqDigQ2j4ihNaT8aIh1kIFF1mbK95/Up8ghDgMZOwa7MUdIuiVpcE0 RlMFIqphIamMjLl4n6toUw2A+1zFGhxnNhzikP8al2oAYRkMPKfh6QHMmxE5hOd+1V9v4G a1nd91rJtd7ng+n2NrRIGRorKdw3/50= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="L5H/r30y"; spf=pass (imf24.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 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=1738817782; a=rsa-sha256; cv=none; b=eKa92NbqaaZHicG55soWGvkRzuG0IBAfwBWhKfg7+Z34bgXKAaRqcwX9kx+Pg8bI0msC/d ms3ZT6mgA2IFNpoi8zvxdh9yy3HAzpw06F5SjIXB/bdhTPHFj4OVFqcoKNWb0xLIbcN5cA Ah8USM9CpgNYsQXnL2A1n1HIDax50Mo= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-307d1ab59c6so4465221fa.1 for ; Wed, 05 Feb 2025 20:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738817781; x=1739422581; 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=553hF+T7BWF2LLgAhHz451B5EJreka9CG49KJHF3jzI=; b=L5H/r30ylcqKllJf/KlO1RvuP4XWEJxQKILhm9ti6UGLj3ULA83k3uHg/M3D504F4q FRuRyeHtAiBbKyyz6NL/3ta2xtpRDE/e5Bi6VIihWtzvSGsYvd8cAIOhioq+1F0ofcBp knaKPqk3NBUq3P3VnjFmjWtuEdK3V2u2dJLlEx44rXE2YFkOaVxrvcNguTTTuYLX1/U6 x8K+k86c91ri0I2+8oVMPhzjhxi0G5YFZCeCGQNLuwy2UzK+x1/ZamuOSFBRnQQKu1Nr hnC82tKb/0J7/s0HD2yknp+0TSQWseUJzBCSBWINHFZdnmQI0uSuAkGfyMbw50nLj3nj Q6SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738817781; x=1739422581; 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=553hF+T7BWF2LLgAhHz451B5EJreka9CG49KJHF3jzI=; b=BoNwAD5XiR8bQnoGrMQGb4/nX/iJp+goBUs4HTUw2oEFHvA/26GSV0ZBEpKD4vGGQJ 3QEznnC92bqrYH/CxHrq4V/g3vSwO3nbtIGzxjaMHYQ/ku9sARZ3WkVU4YPUYDRs4MTo i6eGjJcmWTqZNWZiQ7sBg/RuEhmJIpaU5eD7NqGoY9p7DjhpUyy7kpYn1y0OdrLkvD5g Bw7TJoPwsgAm214qB2duZfny/eADO2TJIbEuCfv1DsdLoUY4K4L7pupFfZgPdoVG1fWW ZE9Ug16GvYIrYGj5+A3ud3bcDaCUJZpxULSXfgf5mmY/V79Dq1koyjxLKiLCwWmuO500 qcjQ== X-Forwarded-Encrypted: i=1; AJvYcCX83YtqmcwUaG209Kim90U7kS5uPUTebB9JkD9+FHfF4nAaGt9sUpLy+IUEIXGdVvUldTgpECkkNQ==@kvack.org X-Gm-Message-State: AOJu0YzkHYAWbbDdjg4vxctTm2p5whCPX0YYVbPw7E+j9mM7dJcoGBU8 UuDIhoLOTCY3u0jE3CQ9ESKNSxPL2TVkypynhmx7PeU/qNKmTPAjS8QsbmCh16EyuOZn/tLdVX4 CbCHRxQxYdasB1blJC44LHrcxUow= X-Gm-Gg: ASbGncvkLadbU3Uk0qEVOCNEI8ufjXAsjT2VcdFZG3TltswdmHYZrTYsR89ka4dLeyV CemdsDRyovUuHtcOtyfZdCCVBrBQT6olhYzIOTQpPDk/L+7Zpu2c0ZeK2dixtUFCpLfQmYZg= X-Google-Smtp-Source: AGHT+IFonN6lOudu0OFZFWXDq7UQ7mw0D1dsFuCqkLDlH0Ywbx7YEuGZX14bATC+gLWbyC0JYnl24IokY0f+9SOIW34= X-Received: by 2002:a05:651c:220b:b0:302:40ee:4c2e with SMTP id 38308e7fff4ca-307cf301980mr21525041fa.2.1738817780478; Wed, 05 Feb 2025 20:56:20 -0800 (PST) MIME-Version: 1.0 References: <20250205180842.GC1183495@cmpxchg.org> In-Reply-To: From: Kairui Song Date: Thu, 6 Feb 2025 12:56:03 +0800 X-Gm-Features: AWEUYZkWAfEEjK0QEPwBPRIyhrI2ANWH_0Fhnn48KPULDYSPjpkjIWKEHfuhVA4 Message-ID: Subject: Re: A path forward to cleaning up dying cgroups? To: Yosry Ahmed , Muchun Song Cc: Johannes Weiner , Hamza Mahfooz , linux-mm@kvack.org, Roman Gushchin , Shakeel Butt , Andrew Morton , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Tejun Heo , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Michal Hocko , "Zach O'Keefe" , Kinsey Ho , Yosry Ahmed , Allen Pais Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9D517180002 X-Stat-Signature: u7qe7q9wzq5edx3w7qgw9wpiujbdtsoe X-Rspam-User: X-HE-Tag: 1738817782-571394 X-HE-Meta: U2FsdGVkX19Ngm86MC3Z8R4Kcs9o7qNPyfhfT3MAZImCKFvnoEkH6+vakeocDnLSzjMFniWF0Qp+RkBHV2u3oVDP/IzqE9VmK52/BCknkeMfdYRCtgbJ2gvf7TOQivzeQJTy6eEArfPU3vO7R6jdz+DdeMwKArMWdscZtRxsBQp9+d9ISCmsZKsHlq/LILYKe9CS3HdEBx8Gl3/tBbzwgpbZWhEYQLgjdEfk+mXifJFBIJ4xAg/2F5sYry/yAmHRlEe/02mlw299RmvnyBBE8NDS7Dg190BcMl27V8feeCjlPwk+Qp1VDJRmEUeyQ06A2fLWTU5+l5WokGZGptipdKopopMeWmuIFOu9nlQ2B4JQzU9xCzCTTtIKy8sww1SDv2+yeB2b3hTHqj1tSxbsKpWpKntcFvOX8sXkUJEtnp1K5MEMP369ehc3dpO54BnqKBP6kuv6dhqcMm3ysrrO+t0wnsAhYMr4rLMSt4FesnuVLIHncvBzSUTObYnii8SYJpYEhnpih58MC4aDYb5LOE06Ta3eZrOwXODTEpteHDz4Ax8oZTyIbPq+krIm94JN/4mMQWU+NPFdXh4PRVpaAgtnqmrWG8WDWCj15basnAzEKwRhZ9YWxO12+swoY2iiwoeykvWWaLu14ErRYfaHFJN1iGF7Y6NjOfu5bvBmyRuY1S3xkXf54eqoKZ8iEvss+gxfS3G0Kb1SyX/go5y/hQRMw3oSp6TyId0+lhtkWDELVsA8N7ymIMVyfaZKYKfC/kr3jw7T6d6TF11AaAJiWU+j+Zjga6Q0YuCoFuP8lv21vuaCQyshv2eZ+SW5wM4q/sHud6S7fFTaZGTQkGijF2xKnsjn4lDNMpwEueDA+7LCsw5RvICgOgU/rQY18lhscALll/QYcnEj8+Xh6zhVUCED8E5fyy78wjPYgAPvO0ISIAGrDsho8Tz/7sQ1W7eVwwEVMFSvE02AzOW37xb 8cUcGUgy oAd8x/uWtsmpGVc431mdwK/dwHAZH1VU/G6VSfHL+bvOzJ0+H30ixTWzK3vrpmw4UshSpSEqAsfaqf8fIUQRHio3Ztjf8PcEcxT7Sff9smhJebcfMjPSqze60Se5Qh/KAnZ1vntfnHkpN0z44mKUXF0be8MnN5ilcOtapNSfWQ8KTHF83Af/njCIaCFIl5GB/oxIb7WqjA+ZjHroGmRmgiRE2wb46F60e0M1c3qrAIesFOeD6XE0gincBEx+dicuXQGRIuSmlZWUobauawJ+kRr0FiWMjURNwEFNEr7d9lCB7Y97yiA28lYIQPy6C/av29rRxiH0PLaMOGktHD0Q+LTKV7t/zNGYSfuygTRDHi73YMdrdLnLVj/+UXA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.007448, 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, Feb 6, 2025 at 2:16=E2=80=AFAM Yosry Ahmed = wrote: > > On Wed, Feb 05, 2025 at 01:08:42PM -0500, Johannes Weiner wrote: > > On Wed, Feb 05, 2025 at 12:50:19PM -0500, Hamza Mahfooz wrote: > > > Cc: Shakeel Butt > > > > > > On 2/5/25 12:48, Hamza Mahfooz wrote: > > > > I was just curious as to what the status of the issue described in = [1] > > > > is. It appears that the last time someone took a stab at it was in = [2]. > > > > If memory serves, the sticking point was whether pages should indeed > > be reparented on cgroup death, or whether they could be moved > > arbitrarily to other cgroups that are still using them. > > > > It's a bit unfortunate, because the reparenting patches were tested > > and reviewed, and the arbitrary recharging was just an idea that > > ttbomk nobody seriously followed up on afterwards. > > There was an RFC series [1] for the recharging, but all memcg > maintainers hated it :P > > https://lore.kernel.org/lkml/20230720070825.992023-1-yosryahmed@google.co= m/ We have been suffering from dying cgroup issues for years too, and I just saw this series. Will it be a good idea to combine this with reparenting instead (if we will go with the reparenting approach)? Using objcg API to charge the folios does help speed up the reparenting, but also adds some overhead and complexity. Just walking and reparenting the folios seems a more direct approach. And another idea is, per our observation, dying cgroups have few pages that are mapped, as the process has all exited. Most folios are just cache. Shared mapped pages are minor especially for containers. So a deferred recharge on access seems good enough? Mapped folios may also be finally unmap someday and get recharged. And at least this makes accounting more accurate.