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 C05DCC32793 for ; Wed, 24 Aug 2022 09:35:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C34A9940008; Wed, 24 Aug 2022 05:35:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE3A6940007; Wed, 24 Aug 2022 05:35:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AABDA940008; Wed, 24 Aug 2022 05:35:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 972FB940007 for ; Wed, 24 Aug 2022 05:35:12 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6D8051A01EC for ; Wed, 24 Aug 2022 09:35:12 +0000 (UTC) X-FDA: 79833977664.02.9201713 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf12.hostedemail.com (Postfix) with ESMTP id 2F1FE4000D for ; Wed, 24 Aug 2022 09:35:12 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id v10so15858984ljh.9 for ; Wed, 24 Aug 2022 02:35:11 -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=GCl8dHqPSzKvC1qvvjcvE0b120LUuRhLO2pWkva8f+U=; b=GstEXS+VfViwMMFI9HBPPaVshMA7v+fU6E0LQ2UW84b7h0tAoknsXgpbrvStzEf8p6 aHTgEit/8mjbIJRRSRjqQkyTybpZ9qjHpci+7CAA2JFANBa9HpMekvB3o+4Ebcl5nwIM nF2pdYIK6LxUdCW+Q8djZYUjpkrYCkZbafYjdD9U2N8TBmEG/r+Gr+UEW27jzJyRozif +rAcIQSy5Uw8kJlnIuswEMcxNWjKkl9gGBnw+Aan0zqqY/1MYB0YYJBOdWAN5hisBrDF NXOsjql7wKVQ+X5UqkHjyRsg2FwE1r2BPa6GXfl8ePOee01L0QVZfoqfNqLxCG8KsoXg qn9w== 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=GCl8dHqPSzKvC1qvvjcvE0b120LUuRhLO2pWkva8f+U=; b=KN8ZLpjjagTW6Ugv3282BcjRvdKTKzKEpDiSOvt2V/wTX8ZD3jGXnvhK+LLtpT3DTV IKxxfmVbrfTQI/1MQeXmh0Y+2mZPJJsa6X/yhNhSb4dLCLwJRY9pFtR+YgAcbBjJ/brz ECDpLyg2rw39oEVAH4sljNHCal43PAJbe2nTueREsVUwdzxk7NtiB+dBefTxIppcJXkJ SW5VI4vGSRKF7mR/1W4gzf1n/s/13fgyxI6p9r6i5nxIfH/aHDZB3D6mNQYKMlly9Bl5 UwjlXbUIhz512t7SwHdBsB+h5H0HGVY6JWkt3hs8W7lme3NuvGyWFPsv2KFXmpB8YwoB hIKQ== X-Gm-Message-State: ACgBeo2ejN7d4g9C5lMXGUGjUmiIO2UCfYlsYPzyjnBEAg96ZV6KA8m4 5qH8WS/EbchzN51MUTpd9t2z4mWwDCHgQ0RFMjs= X-Google-Smtp-Source: AA6agR4kNB8iDWAsESnEdzdfkRFZhXH8xbseiOV/TuKM2jj0O2Om/84Aa7+cv8ErMcnwUyyopAL+Tb1683zvVamx0HQ= X-Received: by 2002:a2e:a80b:0:b0:261:c107:8823 with SMTP id l11-20020a2ea80b000000b00261c1078823mr6263213ljq.323.1661333710483; Wed, 24 Aug 2022 02:35:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhaoyang Huang Date: Wed, 24 Aug 2022 17:34:42 +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=1661333712; a=rsa-sha256; cv=none; b=VGBBuI2GEmKXzLadCehu5xFUD0WoO3rDhlz+DDSoj0TA5flu4IlRVHJFHQiyKJJRSoaUTV eRs3xCnjd7iyuqA6CdHBNoQupMK9stLGoTOtdEXUYp9xo+yPEx2U5jwjcB3jSR0d+IIgFH zdVtWkpC0irs2PQje+bBmYCegB9kbQA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GstEXS+V; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.182 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=1661333712; 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=GCl8dHqPSzKvC1qvvjcvE0b120LUuRhLO2pWkva8f+U=; b=ukfYNBhHRmhfepGY3ZkXlLtmzzSBjYZBbckEw77/wADIMU9aDkMRXywoezfO3bxSCJh/oC SAKEepx4/ASjbvxVy2sEQJz47Kt6mox/E6xNDYXz0CrWqlSin4cz+DLXG6Cmk3ReO5DGJQ ElX9nVG1rNVRV4xETRoPR2WHORo8i9g= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2F1FE4000D X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GstEXS+V; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Stat-Signature: 5qwd8kez487woi18iuao6u48d1yfwxuc X-HE-Tag: 1661333712-314444 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 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. IMHO, charging the pages which out of explicitly memory enabled group to root could solve all of the above constraints with no harm. > -- > Michal Hocko > SUSE Labs