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 09278C04AA5 for ; Thu, 25 Aug 2022 08:50:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71316940008; Thu, 25 Aug 2022 04:50:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69BE1940007; Thu, 25 Aug 2022 04:50:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5165E940008; Thu, 25 Aug 2022 04:50:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3B9C2940007 for ; Thu, 25 Aug 2022 04:50:44 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 14FDA1C75C6 for ; Thu, 25 Aug 2022 08:50:44 +0000 (UTC) X-FDA: 79837494408.01.99C2A53 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id 8EFDC4000A for ; Thu, 25 Aug 2022 08:50:43 +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-out1.suse.de (Postfix) with ESMTPS id 29B9634CB5; Thu, 25 Aug 2022 08:50:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661417442; 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=zP6YQmZN7163OEbBczeU7FAkSDwVdl5LC3HTPoybyrM=; b=FXgUGZB+osz5E4JAckwNcEMAP2NfQm322eTKa+A9/pgC4y/sgW0XuNYetBenNlNDIxO/fw vWwoqK/wBxIIugpIEItM7OO/MDtdysSicXWJ68yqmO/LCq9pJTk8VfZAR9VnTVJV5y6C7h 8JbaOXXlGeGJ4aCK+1vxzqr2MxONwPg= 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 083BA13517; Thu, 25 Aug 2022 08:50:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NoP0OuE3B2PPNgAAMHmgww (envelope-from ); Thu, 25 Aug 2022 08:50:41 +0000 Date: Thu, 25 Aug 2022 10:50:41 +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-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=FXgUGZB+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661417443; a=rsa-sha256; cv=none; b=1HeEnz34WXMHdAqHOGTvJMvKa9/he6IO54l7VhLMCzftUx1Hi2KWwdZ9Kby6Y50Mcxtnb+ YmAPG/rB3kCQW2HMDt3nB+myevLqgajkZyrQok0sfCw+ljdcWP9oFJMBfNkYOzOmX3j2dB 4TYJu/je9+Wrh2h5jHHkMSkW4x+1FnM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661417443; 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=zP6YQmZN7163OEbBczeU7FAkSDwVdl5LC3HTPoybyrM=; b=GjBd+QrdznCu4vKLh7OHrKs+OCkppB6pATAS8RQ7FUbTKRix+TwHlqr5IdeAw3DiZ5RY/6 WjMJE8IUoj+TmyxKI06p+HV8FLeDpo2JF1F/Lq3RCszblxxmJN1jWHwVoocskrN6TWHSam FO/9s+1pdF2i5ShjrVMTMSNK4z1Z1fk= X-Stat-Signature: 594hf5yqwmkdinu8c3ohg7t58in1bwb4 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=FXgUGZB+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8EFDC4000A X-Rspam-User: X-HE-Tag: 1661417443-10959 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 16:34:04, Zhaoyang Huang wrote: > On Thu, Aug 25, 2022 at 2:40 PM Michal Hocko wrote: > > > > 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). > Ok, I would like to know how AA3 achieve the goal of competing with A1 > and A2 for cpu but keep memory out of control under current policy? > root > | > A > controllers="memory,cpu" > memory.max = 1G > subtree_control="memory,cpu" > | | | > A1 A2 A3 subtree_control="cpu" > | | > AA3 AA4 controllers="cpu" I cannot really give you configuration you want without understanding what you are trying to achieve and why do you need it that way. Really, you can construct arbitrary hierarchies and only a very small subset of them actually makes sense. So far you have been very terse at your goals and intentions but rather demanding on the underlying mechanisms. This doesn't really makes the discussion productive. I hope you have at least understood that hierarchical property of the cgroup v2 is a must and it won't change. If you need a help to construct hierarchy for your specific workload I would recommend to clearly state your final goal and reasoning behind. Maybe you will get a more specific help that way. Good luck! -- Michal Hocko SUSE Labs