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 89D79C02192 for ; Wed, 5 Feb 2025 18:31:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B10928000A; Wed, 5 Feb 2025 13:31:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 061CB280004; Wed, 5 Feb 2025 13:31:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6A8A28000A; Wed, 5 Feb 2025 13:31:28 -0500 (EST) 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 C9EED280004 for ; Wed, 5 Feb 2025 13:31:28 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7C511808EA for ; Wed, 5 Feb 2025 18:31:28 +0000 (UTC) X-FDA: 83086733856.07.90784F8 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) by imf25.hostedemail.com (Postfix) with ESMTP id 9BFA8A0012 for ; Wed, 5 Feb 2025 18:31:26 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FrG3Tz5j; spf=pass (imf25.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.170 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=1738780286; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cRpIxuobdJIlfnoT0aXnXGySqVxhsDeVlxOEkWcMenE=; b=PesoqkPWtru36pET80x5ydzBDEnTiq18IH0yDQWY5TawZxO/FOp3f0xArsTm5j9KbhUoAe oN6N/dbvJGhMnvNNSttcPFdh/SFXi0Arf83ufELzX7BDmw4euNvh980rrv+54aPcFm1IIZ SysRqEC/X6c3EKPfarOIGaI9LfWrZeQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738780286; a=rsa-sha256; cv=none; b=k73n4Hk5GATVEi+EMVHrouhN8PyiM+GJdRWD5VDt06OPmVrdOQR2GTXQ1GRwcQGhMtfo1h MDN4j78FkxJ4FBoRtfWGovl83qM4z4oD31iEJDSwy7rTCqLRYQonEuKwhB8yzThewhvrZ8 wNo7AIqHsdmRTGLS3qB3aoKr4IqAFNw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FrG3Tz5j; spf=pass (imf25.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 5 Feb 2025 18:31:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738780283; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cRpIxuobdJIlfnoT0aXnXGySqVxhsDeVlxOEkWcMenE=; b=FrG3Tz5jxfPplMSdfJDAqliNDT/rwj5qayn6aNty0yLNFl10eggjkOv4QxjOkWLTxP8ndU ZNUjrodYYvr5GEGNSvIkR4PIbZLg9CEAo+hQtPfS1FQeXv6IH1ExVqBh/7qdnxwa/TU9wc Qv2acHWk9FkVXpSw8fjOl/6HRm2Imn8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Johannes Weiner Cc: Hamza Mahfooz , linux-mm@kvack.org, Shakeel Butt , Andrew Morton , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Tejun Heo , Michal =?iso-8859-1?Q?Koutn=FD?= , Michal Hocko , Muchun Song , Allen Pais , Yosry Ahmed Subject: Re: A path forward to cleaning up dying cgroups? Message-ID: References: <20250205180842.GC1183495@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250205180842.GC1183495@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 9BFA8A0012 X-Stat-Signature: 3uyaio4pni14gi74b1hupk5g5dghpf5h X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738780286-274208 X-HE-Meta: U2FsdGVkX1+EQULVklN7LafKzZnAZ7Oans54Cuhaz3RVM62UaMdguXKsw1g4rnaWmbN0K0skndgJCQjOi5Z08iMnt89yvZDN9WrfTqlnpcLZ5XifgL7MPhMeShh9fdNpj9hvYG1yiZeFZ8o/TutmSvCEITyrAQ3mbnU7SDylTa30QjB0aNnviI5i0G4K4LdsoVxmP2Qzh/N4hJ8b5EZN5JvVitGrMSAIL4jeUM1Pr0Mts8JIFJRV4dKMUUYpkSwVjjF6gkRhmuNHee9fZYxKvoykHulZFN6g/P/Q64T4XRW2/x5y4PF8spUOmn4ERH3hIp7WsTsLkOmVlDQLjb6szyusuIlcGnZuyJhIr9kW0vR7pduGPA/n4D5+47Fi7UZMEH0Y/n9p9DeEuB1W7p5OszdJIoCTkUdGifmdHpPRu+Mg0VP1sNe+NuY0b4++kv+ldDiyY4nVYEhajHs7OBD2xrpNH0FjxUu9zf7koxymXAFscg8/dS0pq3Cyf7AsybiHYRfs6LItMGp8+ftoP574A3hUTqkCZXEfCvcdqozNneHnV5giB24nWgqYeSSr2Ly/ExIGSeajzf+CUNcy/t+euLehu6ofpCN+ElX37Y9H8NXsj0kFPKKQ98+SJJk+gBeUJruMStOtYvOTPVlO9sPHQwUPPdIenEXOK2M0y2LvpHsZZVroL8LjiTZgGcL48lxC8YFiXKr4z69GH4/LN+6HjKTTb5W9WaLmuCbPXhM4+6FrhzU9TsjaniRD9ihnMjkYYmwcs76yYgMfcE1I/SqsB/igPJe0eZeZ0ipdgpthM/P5SDvis32zmaEvxW8SfTv0woV+i+Fh4b3T937qzSZVKpezzmeIoNR9/6K3Z9IQVykzFp3raezTYfuvoH6e5t4L7Ba2xxCEEhLqu1mLePWom+9RXFOY08DwggpAGlE5GHZ3zM7YOmjAR1v3lwIo7ok3NFZrnlIM5nQAINcvg/7 G0gqo/zc zUo742TKdxMZxDtWVH5L0aYH99snk+IpHwVimEwfVh2ySWaynfkvCFCGMQlBbYddZkn0EvhhnGFhp95tEdyFdFcz6GWJfsWis2mUuVLmq98aZJZzS+k6h2nqs/a/3NIkaRmuS04ypy2HM8YEchFoAiMHXzVa3xd4yHW/WCRyvqDhTC6MFpOYcdJS+A05hvnzD7j6XD6EV26n5s0l/BdlmU09tphNlke++Vi3GSP4vyPGs85lpYAyX35sYZo2b+zHsB5VezcqFOEYPOBI= 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 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. > > We also recently removed the charge moving code from cgroup1, along > with the subtle page access/locking/accounting rules it imposed on the > rest of the MM. I'm doubtful there is much appetite in either camp for > bringing this back. > > So I would still love to see Muchun's patches merged. They fix a > seemingly universally experienced operational issue in memcg, and we > shouldn't hold it up unless somebody actually posts alternative code. > > Thoughts? I don't have a strong opinion here. Reparenting is clearly not perfect, but I agree that we don't have any better solutions, only vague ideas. I believe Muchun's code would require some refresh, but generally is fine to merge. This all comes up to the handling of memory shared between cgroups. Sharing can be spatial (2 or more simultaneously existing cgroups) or temporal (a cgroup is being deleted and recreated, the workload tries to reuse old pages). The reparenting turns temporal sharing into the spacial. It helps with dying cgroups, but comes at the cost of permanently wrong accounting and issues with the memory protection. Thanks!