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 92C23C04AA5 for ; Thu, 25 Aug 2022 10:11:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C5C594000A; Thu, 25 Aug 2022 06:11:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24DF7940007; Thu, 25 Aug 2022 06:11:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C7EB94000A; Thu, 25 Aug 2022 06:11:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EF9AF940007 for ; Thu, 25 Aug 2022 06:11:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C328D121A09 for ; Thu, 25 Aug 2022 10:11:39 +0000 (UTC) X-FDA: 79837698318.30.1FE9A65 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf09.hostedemail.com (Postfix) with ESMTP id 7838114000C for ; Thu, 25 Aug 2022 10:11:39 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id s1so24758304lfp.6 for ; Thu, 25 Aug 2022 03:11:39 -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=vnEJEeMF2AE4KxAkE8pFWCq29ZFBba+mEDUrxnkbubM=; b=mxRAvOKhdn8T9NwgbWp0p3+x7XpqNID2pV90xgRQeuY9cXpHX8jpfcu515trEPmGIk yXpm6WKMG2ujC33kXZlEbt7CFaCFh2qqB2KO+AHFU8Z8NQDWGNqLDBsM+X5i0DnkGX2K dr7liyUGjF4cymJwj1hyeZsoVXLqownOuwKrgcStuLIlTIY/bGCjk7I1DpT1RuA6dQs4 soXomcu2m/MrFqNhsPUFwGIFxOVpa+GANbCZ75+y/TBD/U5JunxlxfAkWtHfFnLaNo/p SU+aK56MqrnU18R7CLczUwjBW7rYEdtcdvgtKogZzNkAQeSKd32wCBNkEOZzQzGioN3t C+WQ== 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=vnEJEeMF2AE4KxAkE8pFWCq29ZFBba+mEDUrxnkbubM=; b=cxEbcwZx2JIxMEFk0HIxEvlyJyFd7X541cGax8CGD0SGB6pdLdk7EdxdOazWwzotEg CmmwRn45luYXHD3pTf+D7mYVgaRvQ7HRRYJ4XjzIxUGIuYp0FAdz5tCp+9yp3WNGNK9i dFsX/gDy5AK3ZhaUIfk+KbyYp7ghOQfbroFklgQtxjKRvmtLo0ekZpH6w0fPoIvrZDDy Z4yGgK5j8wqICGf9BDxJGbifEKSUPY/1ceB9fFwxBt05Ia1Is/OPGC0BNk0pgyG1EDwE JJnGDDY+NLpMvWuagCxwFe5oPKt1NRL9czF4SXEO9W7AY1O7xjsNlydnFG//gRkoYgRD bfQQ== X-Gm-Message-State: ACgBeo13STMmplVqRYTQrwu5Gk3XE5UrnF07kfqQ9g2kQ9GKQofOliyu JPrqFN7xqeNffTydXSlOe40dpzze+BEyuZMCLkY= X-Google-Smtp-Source: AA6agR4WDEjZYCMKzLQ4hunM2CsnlULc04fC2EaGu4C97BcS6jbk5YsGslWkhMuPW5GZ2NobTkCo9Dua51UO6zGXQyw= X-Received: by 2002:a05:6512:3049:b0:492:f394:11cd with SMTP id b9-20020a056512304900b00492f39411cdmr998982lfb.165.1661422297676; Thu, 25 Aug 2022 03:11:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhaoyang Huang Date: Thu, 25 Aug 2022 18:11:09 +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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661422299; 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=vnEJEeMF2AE4KxAkE8pFWCq29ZFBba+mEDUrxnkbubM=; b=Mmuw/q8SFgF8dDfIP/Adrqooyvd3uhyrDfiZeWprEi43OKx3eQZH8lUh1S/KF5fExHw0G1 PqfYXMnE+9Y2KCb8rU9w11LJhuayuUpftUCFSVpWXqjc1dS3eHcj6YqLbTwuljQGWBY3bk UwaVAEBclGLITclU4kEHXes0BvCppsg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mxRAvOKh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661422299; a=rsa-sha256; cv=none; b=w+X6BhYYGYrZvhNRezaC/Me4+pwB/8GvhV2fpelSC8umEBK3jv/enALxXjnOy0eYeoQ3Pb XlxREwPonvlNzRklG/fL0mUIGoUYmcROF7SXyoc0zZHmJhHW1EDT24nkveTZQhbRZfFnXu cb7CSoI8OEaXLfU2qLpYK0dQvP38nGY= Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mxRAvOKh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Rspam-User: X-Rspamd-Queue-Id: 7838114000C X-Rspamd-Server: rspam10 X-Stat-Signature: 7yg9d6zxnuzt7jfb9bmsxex8thpia64c X-HE-Tag: 1661422299-606538 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, Aug 25, 2022 at 4:50 PM Michal Hocko wrote: > > 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! Sorry for any misunderstanding among the discussion. My purpose is real and simple as I have stated from the very beginning that I would like to have per-app cgroup hierarchy to charge memory to root if it is not enabled explicitly for memory. The reason has also been stated like reclaim and workingset regression in suren's report. I don't think my proposal will do any harm to current v2's mechanism besides asking for the admin echo "+memory" to their desire group. > -- > Michal Hocko > SUSE Labs