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 CE8B2C32774 for ; Tue, 23 Aug 2022 06:03:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 360566B0073; Tue, 23 Aug 2022 02:03:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 310038D0002; Tue, 23 Aug 2022 02:03:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D8BF8D0001; Tue, 23 Aug 2022 02:03:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0E2F56B0073 for ; Tue, 23 Aug 2022 02:03:35 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DF6B11A14D5 for ; Tue, 23 Aug 2022 06:03:34 +0000 (UTC) X-FDA: 79829815548.11.E18BCB6 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf08.hostedemail.com (Postfix) with ESMTP id 915D316002E for ; Tue, 23 Aug 2022 06:03:34 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id l23so1505975lji.1 for ; Mon, 22 Aug 2022 23:03:34 -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=E62vcG6bv2NNKCtD/xZSrhG3tjB/Yn/YnvPEoQsQ9jU=; b=i9pQ/jlf23urfzZGcT78wq4iwrCpsCF/RBEu56tcMGOPHmkNCYJyLUlDhCzToM/tns VXlAupSv9gmHQiLAijfbheKjUISV7fLTvvwCc/Bq099q1/FKTE3B5yvgGOjyDi4oaVR1 2MUmxB34Ls2U41/lrPnegBKEhxSrDoU3rHrUMgRPe2O7JLkd0Uw0EbRcmV663aAdE9J2 XyRs3+ZuOQcfs5fEi6Yv1O32zi/7ALmMyDLGatsIrJCDHEZLD95v5/WDa1I7j9D+dtPS CveXtZXWpglnln7WRxUW2BurJCt+giTZ3gowKTC9U4Z4jRjmGbHjOc5hrhGukOza0LoD jkow== 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=E62vcG6bv2NNKCtD/xZSrhG3tjB/Yn/YnvPEoQsQ9jU=; b=owZmtyxkBhWuQe4Zy/MKlYWLfsU7ZoWIKYu11qO1PdiaZ+cXrHi3kVnz9EcunWaOve JWzexCqbfdX7mgnOXMyq07DhCV8JQZkvkZi5RLTKz8/mJ/5QFW656LRxv/6xpfTeeOxJ 3Buuhqub+QT4s6OH/7Pv9mEzCvVdPUCzOS3r5jFMNUYvEOym5xJXSh6KWEobZURZHWmi CJ7ZJ8x+CQs2FnOrqXN2XqXvmKKHhOdzsTsatFwMNqnAPFW/8dwo17HIzsPziuH41JsD TsyFJjdhQb7n0DNHKRRSj0cCb6/boKGdiFhRPVrtFJs0dgdPrSqlf7PRlJuiNOewz/4Z 74uQ== X-Gm-Message-State: ACgBeo0FNhVFKCmMs6R4e7fbfZQKaWecFsouZrNPjR2D7FUraz8SvH5w l5408TaSgulRYpJdRInx56972m/+8gDmp3j+Fgo= X-Google-Smtp-Source: AA6agR6zN9oIh9MYRCAAGDxl0xMdUfhVW/LqXRolx5mCBjnzeCCMkmhYgnVODUm5K8SWlRonG7SrNkD1K8Aa/nul9bU= X-Received: by 2002:a05:651c:2311:b0:261:d3d9:52e6 with SMTP id bi17-20020a05651c231100b00261d3d952e6mr1267222ljb.392.1661234613072; Mon, 22 Aug 2022 23:03:33 -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 14:03: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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661234614; 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=E62vcG6bv2NNKCtD/xZSrhG3tjB/Yn/YnvPEoQsQ9jU=; b=sxVvLYquStb4p6eZX8mdhRFmF4QwUEJyTky/kLhFTagdPVp/aXCmbRq7DeBZWz1NngOxkZ QSAb2PDWMF6y+yMFYAsjtAJw44IfcHA5kvmR0tIGDr6H8/qakCm7pIw9bXV5GoJ70vpFKb 1FiQk7KY68hb3+zyqEkkl/5e0d3S16U= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="i9pQ/jlf"; spf=pass (imf08.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.169 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=1661234614; a=rsa-sha256; cv=none; b=HWNChnwA660i0oU8coqXtYZhFTa/p+Hw0/P1BGZZic1I8PcMRfzgJq+alVFnw2V1oH1UXP nVspWB6A3188djEgg1/6gadaTuwH1q5cM5MNv8RCwDbt/zZoJ5GeXrmWie48Cy3GUTi1p5 xKEBmzaVPiNPalOiCgK/vpNTk5XAmys= X-Rspamd-Queue-Id: 915D316002E X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="i9pQ/jlf"; spf=pass (imf08.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-Stat-Signature: 1h5dqr1soxepy3es8w6sosas9d4gkqy3 X-HE-Tag: 1661234614-721331 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 1:21 PM Michal Hocko wrote: > > On Tue 23-08-22 10:31:57, Zhaoyang Huang wrote: > > On Mon, Aug 22, 2022 at 7:31 PM Michal Hocko wrote: > > > > > > On Fri 19-08-22 07:10:26, Tejun Heo wrote: > > > > On Fri, Aug 19, 2022 at 10:08:59AM -0700, Shakeel Butt wrote: > > > > > On Fri, Aug 19, 2022 at 9:29 AM Tejun Heo wrote: > > > > > > > > > > > > On Fri, Aug 19, 2022 at 07:29:22PM +0800, zhaoyang.huang wrote: > > > > > > > From: Zhaoyang Huang > > > > > > > > > > > > > > It is observed in android system where per-app cgroup is demanded by freezer > > > > > > > subsys and part of groups require memory control. The hierarchy could be simplized > > > > > > > as bellowing where memory charged on group B abserved while we only want have > > > > > > > group E's memory be controlled and B's descendants compete freely for memory. > > > > > > > This should be the consequences of unified hierarchy. > > > > > > > Under this scenario, less efficient memory reclaim is observed when comparing > > > > > > > with no memory control. It is believed that multi LRU scanning introduces some > > > > > > > of the overhead. Furthermore, page thrashing is also heavier than global LRU > > > > > > > which could be the consequences of partial failure of WORKINGSET mechanism as > > > > > > > LRU is too short to protect the active pages. > > > > > > > > > > > > > > A(subtree_control = memory) - B(subtree_control = NULL) - C() > > > > > > > \ D() > > > > > > > - E(subtree_control = memory) - F() > > > > > > > \ G() > > > > > > > > > > > > > > Signed-off-by: Zhaoyang Huang > > > > > > > > > > > > Just in case it wasn't clear. > > > > > > > > > > > > Nacked-by: Tejun Heo > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Was there a previous discussion on this? The commit message is unreadable. > > > > > > > > http://lkml.kernel.org/r/1660298966-11493-1-git-send-email-zhaoyang.huang@unisoc.com > > > > > > Even that discussion doesn't really explain the real underlying problem. > > > There are statements about inefficiency and trashing without any further > > > details or clarifications. > > 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. > > > > 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 > -- > Michal Hocko > SUSE Labs