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 08230C28D13 for ; Thu, 25 Aug 2022 08:34:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86C5F940008; Thu, 25 Aug 2022 04:34:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81BC4940007; Thu, 25 Aug 2022 04:34:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E3F6940008; Thu, 25 Aug 2022 04:34:34 -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 5F47A940007 for ; Thu, 25 Aug 2022 04:34:34 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 32ED31C74A0 for ; Thu, 25 Aug 2022 08:34:34 +0000 (UTC) X-FDA: 79837453668.13.A824A16 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf17.hostedemail.com (Postfix) with ESMTP id EB61E40002 for ; Thu, 25 Aug 2022 08:34:33 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id by6so18701741ljb.11 for ; Thu, 25 Aug 2022 01:34:33 -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=H+0hvgnQryLyRGTLY2PSvbtKINzM1C3o/madftxyfvU=; b=hUs2zEarOFOjldcG3/iN1PjdwMaKcwDVlAxhiVE1FNpVdYCy9CBiFFc0u4vGdOhtTJ Zjf7OoJfwwqcqxxmkppcrILJB9/dXeYYO4zQnglsljh9LY6b31UWtcvuyN2xpMf5+91r pgv+hOaa4lZvxqNvi0bAfaF/LNas8FXjjBy68uXz5htwDQqKbfvUl0XMYV7OiDZ03ZCn kakLDuYy35p7tQLQr19m2+/EHNOYoK521heqvB/5pGDWO0PBTrkmq95thaBW04NEYDOp f6QFGMSBJepxO1H2h7tEoGwlalN8ez1DlEJF24r4AXehRuV/Dwkl0LsnKM+ZSeK+ROZ/ lVIA== 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=H+0hvgnQryLyRGTLY2PSvbtKINzM1C3o/madftxyfvU=; b=RdyZiOl77ljnIeVxQVTnXRVuDD5ZB2dSpbQR3KnPAHRVAyuU8UHVkc0y/E9PXKI078 9CJD1Lqpucorz6SyjAht+dfbuvbgsSNCKClcpzPtIf39oIYYQyxOjJg4PfLgIjM5jjZ8 rYvw9qh2MIIAiqNT1MKVIs7ogpYh1JQ/a+2z9SJx/R5cv+hEkZUBUTye1aW6GZ7AT4zR IoK8y5i/Tv6dPZ9ui2tx7E26dRj5wirAb/aAiCJvVjl6D/siBGhzTjBqzCbvr+EWgY27 MQR8KLY5brN4E3Wi37wYFLI+F4Q+8UmpHmVL+9mnY+FAFe5Ak4TLOzqUSBdJFNaBYWPq eWCA== X-Gm-Message-State: ACgBeo03yIY5yPkyjuH6fNn05AXYKjnB638LJB/Z2JIttx3suozEuQR/ eDYdL+lsPunWW8JFAqhltB/FLhwv/dsABwIPK7o= X-Google-Smtp-Source: AA6agR6W86PKJOKHWZb0C5IbJSjh1Hz+Isg368Kgq9FRsMX5RsH85N8hSo46BIPNsGyMnJDj1JDAQU/Q7kmv9R4AhjA= X-Received: by 2002:a2e:3817:0:b0:261:cfba:ee4c with SMTP id f23-20020a2e3817000000b00261cfbaee4cmr732301lja.443.1661416472267; Thu, 25 Aug 2022 01:34:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhaoyang Huang Date: Thu, 25 Aug 2022 16:34:04 +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=1661416473; a=rsa-sha256; cv=none; b=wQKkwBSmY48QG8lP25FXdmlcFa51wHo3y93+3lCbazJ1yXlugn+sFkb5yXkiHgiqJhXRkx z3h+H147J6C5Xl5FCFIqjDWphxqBPc6F5bsud2Fma7AJ1j3LVlIY7cRkP7FowQkT3WXd1s vMlCak1RXZxkWlSO8ZH1yKK9QshZVx8= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=hUs2zEar; spf=pass (imf17.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661416473; 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=H+0hvgnQryLyRGTLY2PSvbtKINzM1C3o/madftxyfvU=; b=esNJgjVgKTsSnlEbxDC2S3aRppIR643fDTFxGx2sXgQzllVGCRr0XREC2vkXyH+0mm87gT Lpu4WmERfgIK5mU15uRAXjVIxyQAAIfxD7eq1TXORZ2il7bF1tTQxBXedWbnkaFyJGG3YP C8UeXQFFeYjne8GG/ul7bStD4jEaUrY= X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=hUs2zEar; spf=pass (imf17.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam12 X-Stat-Signature: gdm3d49ichj5t6e7nnxf9dzm4ub8w1q1 X-Rspamd-Queue-Id: EB61E40002 X-HE-Tag: 1661416473-932482 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 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" > > -- > Michal Hocko > SUSE Labs