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 E9764C04AA5 for ; Thu, 25 Aug 2022 06:40:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DEBE6B007B; Thu, 25 Aug 2022 02:40:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18D0A6B007D; Thu, 25 Aug 2022 02:40:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07D15940008; Thu, 25 Aug 2022 02:40:53 -0400 (EDT) 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 EF53B6B007B for ; Thu, 25 Aug 2022 02:40:52 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A0997161660 for ; Thu, 25 Aug 2022 06:40:52 +0000 (UTC) X-FDA: 79837167144.02.7AB7772 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf14.hostedemail.com (Postfix) with ESMTP id 3DCB1100006 for ; Thu, 25 Aug 2022 06:40:52 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id D76AE5BE15; Thu, 25 Aug 2022 06:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661409650; h=from:from:reply-to: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=8tP0U7uO6jkjoWoaVJTMGffTLHsMTAeM7ZO+0Ttzpnc=; b=Rlq2EbXz/KoWktPrNnKN7AIXIeIrydmCssc+ZXhRb8K/2E3gz3XlPnDJOGqi2IIcPcmtAO /gA127K196XnzQb58YhLdftTVYTGJzLNuLnqgaP2dPun3n3mKuze7iKY/qiq73UzJvHzsO XCPRI/PrCt8PtA7mhOsqkjocr6NW3hs= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B8D2C13A47; Thu, 25 Aug 2022 06:40:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SRPaKnIZB2OIOwAAMHmgww (envelope-from ); Thu, 25 Aug 2022 06:40:50 +0000 Date: Thu, 25 Aug 2022 08:40:50 +0200 From: Michal Hocko To: Zhaoyang Huang Cc: Suren Baghdasaryan , Tejun Heo , Shakeel Butt , "zhaoyang.huang" , Johannes Weiner , Linux MM , LKML , Cgroups , Ke Wang , Zefan Li , Roman Gushchin , Muchun Song Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661409652; a=rsa-sha256; cv=none; b=1H2Lj1OckdYi4/9/5gyrHLRsF4pQK/og6v9HFbFkLijcR6tl3tH1V38847znDzOzygx3Ir nlLP/HHzfp2ZyKsbKfbRlYcqLZ8KpfwUXygzhkvNbpNX9v0g2rR5zj6PlZAsccFNgTSRzg Y4IMFFHHCJw6BXdB6HF6bM5zuSA2+q4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Rlq2EbXz; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661409652; 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=8tP0U7uO6jkjoWoaVJTMGffTLHsMTAeM7ZO+0Ttzpnc=; b=BsOAly3NLwJCbsD2Vm1fYtnesnI8//6QyQLxA0f+pGSMZoCq9K9JR/RT0kF6HC234p+E0T zckk0xkfbq7uqtTBng+6p0SfTHQgegUfm4AqKfBZEjla41asWCAjXAGMv4VALywKPi2lYY dXBOa6Z/rvdJ3ml/OCaJqphBVtzqBFw= Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Rlq2EbXz; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-Rspamd-Queue-Id: 3DCB1100006 X-Rspamd-Server: rspam08 X-Stat-Signature: 6uyicxj6hpfs11bzgz8phdchkyoabo3w X-HE-Tag: 1661409652-240950 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: On Thu 25-08-22 08:43:52, Zhaoyang Huang wrote: > On Wed, Aug 24, 2022 at 6:27 PM Michal Hocko wrote: > > > > On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote: [...] > > > IMHO, charging the pages which out of explicitly memory > > > enabled group to root could solve all of the above constraints with no > > > harm. > > > > This would break the hierarchical property of the controller. So a > > strong no no. Consider the following example > > > > root > > | > > A > > controllers="memory" > > memory.max = 1G > > subtree_control="" > > | | | > > A1 A2 A3 > > > > althought A1,2,3 do not have their memory controller enabled explicitly > > they are still constrained by the A memcg limit. If you just charge to > > the root because it doesn't have memory controller enabled explicitly > > then you just evade that constrain. I hope you understand why that is a > > problem. > IMO, A1-A3 should be explicitly enabled via echo "+memory" > > A/subtree_control since memory.max has been set. You seem to be missing the point I've triedy to make here. It is not about how the respective subtree should or shouldn't be configured. It is about the hierarchical behavior. Configuration at a higher level should be enforced under subtree no matter how that subtree decides to enabled/disable controllers. Such subtree might have beeb delegated and configured differently yet the constrain should be still applied. See the point? What you seem to be proposing is similar to cgroup v1 use_hierarchy configuration. It has been decided that this is undesirable very early in the cgroup v2 development because it make delegation impossible (among other reasons). -- Michal Hocko SUSE Labs