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 49C3AC3F6B0 for ; Thu, 25 Aug 2022 00:44:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B8F1F940007; Wed, 24 Aug 2022 20:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B3DF56B0075; Wed, 24 Aug 2022 20:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A045B940007; Wed, 24 Aug 2022 20:44:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8D2AB6B0074 for ; Wed, 24 Aug 2022 20:44:22 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5C441140473 for ; Thu, 25 Aug 2022 00:44:22 +0000 (UTC) X-FDA: 79836268764.26.8D15360 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf22.hostedemail.com (Postfix) with ESMTP id 19772C004D for ; Thu, 25 Aug 2022 00:44:21 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id n15so5106911lfe.3 for ; Wed, 24 Aug 2022 17:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=A/Iio860rhP/v2AnpLJlwrYJYcXyV6DIv9JQx+170rEWmlIhMRzeZ9l+nUAUWh62JI c7+HUkhuYDhePhYz0hBnDIf0kxXPYT4M/ZBV+H/mccKyYUoThe086rHM/Idvobh7usXz aQ9wrACY0Z3JXJeCVGOVmQknpIZLf36WPkxiBD7fWy8VN+O7qbUFOBo3a44ClzdymCK8 cn9zOMWbhdyIyrwdxiUZa+HtMGxS+1GXqgQbAaeZcF6rDiKxojIsL57dVyKueIzEDW5i YgPIUJJ32Dna6ii+VrXwF0fLGL78HBDUuiwmooSSuF5KJzA6EQ+rvmtMerH7qMgXror3 KaSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=HUAlRrqc4tJBH/F1sVk4D/i4K3yTVxD7ZfPQTnReZgrudhZreL5lUz+cfK8gvcYjUY v8k+QnRO67CNEcfjwsjPxDCHDuCB1t+bO/cjPOAiek2dxYHwgSNAB49Wu+oNMBEWSFaM FAIvdasDUC85lCVlZsDEot1B7zJ7Yg61ZF6kF+H5oT1mpETR+7SZ/XPbewAaZ0IbihB3 QW4hcDg8PweAgcW/oWs57+C18lj8tSnCjcilBMNGeX/ZJCGZ88TjL/9Uvd/1pkkz6IwL LWuCBq5qLo/1RoCArc3TMLOAnfb9P/9rzZtSWw8ym2RyasK1b0CEYwiN7Ry+f0MyFhgQ XSAA== X-Gm-Message-State: ACgBeo3YEsZrlY2RHIjAOGj4Y/MhY+jTMKSVWv3c3xAvNKcxX/ORtLC5 aSiXCTHm9MIGoasRK8XHB7yw77OqEUuuA/dflnU= X-Google-Smtp-Source: AA6agR4sZ+jOQ3X+L+bTqjmbitY0TBSZsnZdxwNoCqHbQQL3VjTrTMF6ph0SwWt+X5NwBlfDz2Rm7C9UXN28W6P64Jc= X-Received: by 2002:a05:6512:1527:b0:48b:99:f3ff with SMTP id bq39-20020a056512152700b0048b0099f3ffmr386714lfb.81.1661388260398; Wed, 24 Aug 2022 17:44:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhaoyang Huang Date: Thu, 25 Aug 2022 08:43:52 +0800 Message-ID: Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited To: Michal Hocko Cc: Suren Baghdasaryan , Tejun Heo , Shakeel Butt , "zhaoyang.huang" , Johannes Weiner , Linux MM , LKML , Cgroups , Ke Wang , Zefan Li , Roman Gushchin , Muchun Song Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661388262; a=rsa-sha256; cv=none; b=0sSufhi9qn57XdHs4vB6RgNvVUT75LSn8DwOBAFHYanO1bzTggfqpVWTvwlP9WAzvRhJP8 JRj6CgvrgmX04T2WHbxcibd07fSEc21ie/4qoSI2avWBsa41OQMG0QXELPiRIhlSOyEY99 dBi3+2ktqG53ET2U7LYaVIoisjvtTLA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="A/Iio860"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661388262; 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=u5GpYKAPqiPXiVflxFFAVwYjhQ2xT4l31F3rdQnDD0o=; b=axdzWithwsLcLNbuR5t8yhbVeJfJdRP1ZzlNoqPbt/ISaEonMarlFiKM/BqnWcOqG2jJCM 47LEAxENiwBcKeYLtCfzkUl6+40N+SCgsBlGjEtegjXfubs2SZqEcqKwcFslqaGKkCPTPp BknhwHXSGFeEuadJKXcFWyucsGYd5yA= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="A/Iio860"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Rspamd-Queue-Id: 19772C004D X-Rspamd-Server: rspam02 X-Stat-Signature: sjt6fr15q1zh1a1eusohioeyijribk6a X-Rspam-User: X-HE-Tag: 1661388261-501925 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 Wed, Aug 24, 2022 at 6:27 PM Michal Hocko wrote: > > On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote: > > On Wed, Aug 24, 2022 at 3:50 PM Michal Hocko wrote: > > > > > > On Wed 24-08-22 10:23:14, Zhaoyang Huang wrote: > > > > On Tue, Aug 23, 2022 at 7:51 PM Michal Hocko wrote: > > > [...] > > > > > One way to achieve that would be shaping the hierarchy the following way > > > > > root > > > > > / \ > > > > > no_memcg[1] memcg[2] > > > > > |||||||| ||||| > > > > > app_cgroups app_cgroups > > > > > > > > > > with > > > > > no_memcg.subtree_control = "" > > > > > memcg.subtree_control = memory > > > > > > > > > > no? > > > > According to my understanding, No as there will be no no_memcg. All > > > > children groups under root would have its cgroup.controllers = memory > > > > as long as root has memory enabled. > > > > > > Correct > > > > > > > Under this circumstance, all > > > > descendants group under 'no_memcg' will charge memory to its parent > > > > group. > > > > > > Correct. And why is that a problem? I thought you main concern was a per > > > application LRUs. With the above configuration all app_cgroups which do > > > not require an explicit memory control will share the same (no_memcg) > > > LRU and they will be aged together. > > I can't agree since this indicates the processes want memory free > > depending on a specific hierarchy which could have been determined by > > other subsys. > > I really fail to understand your requirements. > > > 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. How should AA3 achieve the goal of compete with AA4,A1,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" > -- > Michal Hocko > SUSE Labs