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 BCA53C32792 for ; Tue, 23 Aug 2022 09:21:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2238E8D0002; Tue, 23 Aug 2022 05:21:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D2F68D0001; Tue, 23 Aug 2022 05:21:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09AEF8D0002; Tue, 23 Aug 2022 05:21:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EEC0C8D0001 for ; Tue, 23 Aug 2022 05:21:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C95DD1214C1 for ; Tue, 23 Aug 2022 09:21:29 +0000 (UTC) X-FDA: 79830314298.10.C1E4DF5 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf09.hostedemail.com (Postfix) with ESMTP id 66AC0140043 for ; Tue, 23 Aug 2022 09:21:29 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id bt10so5854865lfb.1 for ; Tue, 23 Aug 2022 02:21:29 -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=+DWGPIPc3ISzDYgpuxxTGtSNnOcnHXPhDpdYriuehoA=; b=W+2mwoq3OWMQOasY34q5ndf9QlyFCqrsVYi8MwQDe1BCxhmcZpZ0Z1p+h0jGQpBVe5 YI9nZKuyu12VLCXV5aKWyXzAhYFJubm5BcTqhOm5wrL2+a9v0L3eEFhNb94C8Abjpofk H0FkmNc+BE+pbY/Jr172MT/PHEpCKyW3hnF2iqXiX5hvBxOZ/qMwweAvrRfGGGPP9cMA PGbqH0aMl7DQRqBGNw6Li+N3SzBnJJrYXLBoPOnFpF+kdMmRbo657HDBtrY4+QrpjzCd 0mnRokYL7mKXy66KYnO+0RA+rYX2cxrA4dx4W+HwqBjtx4j2xBHFHBg81zAcG6FZrpes b2jg== 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=+DWGPIPc3ISzDYgpuxxTGtSNnOcnHXPhDpdYriuehoA=; b=4poi97EhBb0Yu0CimgKAY8CZYOu4m6+2320vltL4dYLfk2z+rWMcnXI3pys/nH8g21 ykpltLgF3P231cPJocMAMMSzpEH43arYXy25kzz27vsEWeP9eDK4SzNLpMEprtshjgx2 3NfODBKMH7QEnCtkrpv2xdwBXn86rHmbsZc/6KCAl1PUWc+OEBNzICb0l6CpxqaZh7PU iYq8iwLgVOs6gr6L78ayNygAyEhvkerghWpkvEgfd+rAtZtB7cI3gB2eCbXWiev2LEDm sKC6WY+dI02Exe2iept3gnjkVCnLJwCOwPqTiblstAlyRpF/2/6VA14lpY/fG6NvQYyJ 6OJw== X-Gm-Message-State: ACgBeo1XdTpiMvCcHQh8B7RJNu2p/gSSWYdn5FXYFGgjIJBbu2Ss63Vq 4zx5cNPmPfhPFqKxrQydHpL/+tPak4/fY9Iv9Ic= X-Google-Smtp-Source: AA6agR4+KWoZ7AaIB7FncIy8FTWaR54rys+sYhXWsAOHt1uJIh9H5Lnf6SzVrLAGohOucXvT3iQ9PYabEoIZSSYmXNA= X-Received: by 2002:a05:6512:68f:b0:492:cbb1:c4b2 with SMTP id t15-20020a056512068f00b00492cbb1c4b2mr7138192lfe.130.1661246487607; Tue, 23 Aug 2022 02:21:27 -0700 (PDT) MIME-Version: 1.0 References: <1660908562-17409-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Tue, 23 Aug 2022 17:20:59 +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=1661246489; 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=+DWGPIPc3ISzDYgpuxxTGtSNnOcnHXPhDpdYriuehoA=; b=cpNNhz5FOptrSyk947PKNMo5eLC568F/GadOiHDW4SmuPC/e1zHWpZvFpN/QS7PRlNjZYs NK4BZKvn9pFj7P09JvnQ2HFWXypXzn75uyx4LX+OTEN5fRK6xf9SIJyNfhtXKv4Rb1ik5T OOpeBeguLgyO9Vf1g/8Wc6k8/lzoI3A= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=W+2mwoq3; spf=pass (imf09.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661246489; a=rsa-sha256; cv=none; b=A77nlwlcf3m/WCkG+mxG5iiB5tvPX+FEYeSpNf6vWMqThRdlhMnpv/y61ln6+LL0fvwl2o aiqVSRAfB2RBCb5mGBL2uJwePLJE1wfpfripkHxr/vgaSDa4T2snpSoXdecbAMNCxDumx9 p27sEzGjnafqBY/gjXSscMHlxXD7XZc= X-Rspamd-Queue-Id: 66AC0140043 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=W+2mwoq3; spf=pass (imf09.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-Stat-Signature: zywehyk3uraz8os1b9qfzcd1hhhkhk73 X-HE-Tag: 1661246489-289265 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 Tue, Aug 23, 2022 at 4:33 PM Michal Hocko wrote: > > On Tue 23-08-22 14:03:04, Zhaoyang Huang wrote: > > On Tue, Aug 23, 2022 at 1:21 PM Michal Hocko wrote: > > > > > > On Tue 23-08-22 10:31:57, Zhaoyang Huang wrote: > [...] > > > > I would like to quote the comments from google side for more details > > > > which can also be observed from different vendors. > > > > "Also be advised that when you enable memcg v2 you will be using > > > > per-app memcg configuration which implies noticeable overhead because > > > > every app will have its own group. For example pagefault path will > > > > regress by about 15%. And obviously there will be some memory overhead > > > > as well. That's the reason we don't enable them in Android by > > > > default." > > > > > > This should be reported and investigated. Because per-application memcg > > > vs. memcg in general shouldn't make much of a difference from the > > > performance side. I can see a potential performance impact for no-memcg > > > vs. memcg case but even then 15% is quite a lot. > > Less efficiency on memory reclaim caused by multi-LRU should be one of > > the reason, which has been proved by comparing per-app memcg on/off. > > Besides, theoretically workingset could also broken as LRU is too > > short to compose workingset. > > Do you have any data to back these claims? Is this something that could > be handled on the configuration level? E.g. by applying low limit > protection to keep the workingset in the memory? I don't think so. IMO, workingset works when there are pages evicted from LRU and then refault which provide refault distance for pages. Applying memcg's protection will have all LRU out of evicted which make the mechanism fail. > > > > > > My very vague understanding is that the Android system would like to > > > > > freeze specific applications and for that it requires each application > > > > > to live in its own cgroup. This clashes with a requirement to age and > > > > > reclaim memory on a different granularity (aka no per process reclaim). > > > > > So in fact something that cgroup v1 would achieve by having 2 > > > > > hierarchies, one for the freezer which would have a dedicated cgroup for > > > > > each application and the other for the memory controller where tasks are > > > > > grouped by a different criteria. This would rule out that a global (or > > > > > any external memory pressure) reclaim would age LRUs that contain a mix > > > > > bag of application pages rather than iterate over per-application LRUs. > > > > > Is that understanding correct? > > > > Correct, this is just our confusion. Besides, we believe that charge > > > > the pages to implicit memory enabled parent control group doesn't make > > > > sense as the memory cannot be managed at all. > > > > > > I do not get that part. The parent can manange and control the memory > > > usage so how come it cannot be managed at all? > > What I mean is the kind of parent which is enabled implicitly by > > enabling on its sibling group like belowing hierarchy. Imagine that C > > has no intention of memory control but has to be enabled as B would > > have it. IMO, it doesn't make sense to charge C1's memory.current to C > > until an explicitly echo "+memory" > C/subtree_control. > > A----B---B1 > > \ C---C1 > > So let me just expand your example for clarity > > A.cgroup.controllers = memory > A.cgroup.subtree_control = memory > > A/B.cgroup.controllers = memory > A/B.cgroup.subtree_control = memory > A/B/B1.cgroup.controllers = memory > > A/C.cgroup.controllers = memory > A/C.cgroup.subtree_control = "" > A/C/C1.cgroup.controllers = "" Yes for above hierarchy and configuration. > > Is your concern that C1 is charged to A/C or that you cannot actually make > A/C.cgroup.controllers = "" because you want to maintain memory in A? > Because that would be breaking the internal node constrain rule AFAICS. No. I just want to keep memory on B. > > Or maybe you just really want a different hierarchy where > A == root_cgroup and want the memory acocunted in B > (root/B.cgroup.controllers = memory) but not in C (root/C.cgroup.controllers = "")? Yes. > > That would mean that C memory would be maintained on the global (root > memcg) LRUs which is the only internal node which is allowed to have > resources because it is special. Exactly. I would like to have all groups like C which have no parent's subtree_control = memory charge memory to root. Under this implementation, memory under enabled group will be protected by min/low while other groups' memory share the same LRU to have workingset things take effect. > -- > Michal Hocko > SUSE Labs