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 CD22BC28D13 for ; Tue, 23 Aug 2022 02:32:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AB5C6B0073; Mon, 22 Aug 2022 22:32:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35AFD6B0074; Mon, 22 Aug 2022 22:32:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 223418D0001; Mon, 22 Aug 2022 22:32:28 -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 12DBE6B0073 for ; Mon, 22 Aug 2022 22:32:28 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D8E15141364 for ; Tue, 23 Aug 2022 02:32:27 +0000 (UTC) X-FDA: 79829283534.21.A966608 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf18.hostedemail.com (Postfix) with ESMTP id 872D31C000D for ; Tue, 23 Aug 2022 02:32:27 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id bt10so4851876lfb.1 for ; Mon, 22 Aug 2022 19:32:27 -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=azDpKc6FmKTWyiu0fmvIHIHwLpZTiSK1Vlo7KGhRPTI=; b=mOKeqhKYQhMwTLb/MJ8y4BKHtrVT0tL2CLpCqVd982RWh8CKypL1YXMQXH9RXkOYQr svAS8E3tjh/3TZXskHT6eiLzVii7BtFjyyzENE09sgcCl7PJOTZQWNQD8oFDmCLcPXxa R/SMm/X+qEvkdwTnfYLBoFOyLKxMa7H4tewBNQKxpr2iMRa4oHMf6GfZsxsD05kpWw6K L/savuxwWhzpBfzVfVKYEpe6LpvurZbJQkwKDJE7yHE72w3Ud+yG4pGeBHqQHKtM7eGC 4y4R1fkzSDJznz1sFG8M7pcRZw1BIJ/Zv3f9VGj0uvD2h7jmIDOaTWdLm9GEI9Yyev0m 4fOA== 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=azDpKc6FmKTWyiu0fmvIHIHwLpZTiSK1Vlo7KGhRPTI=; b=5pQiDTvl7Jcu+mYNAKB2yaud6b3RSpcw8LAJGbijO0Ed/ukF/pPAb1Na0q24+RowMZ y47lcWLISlnYnJtUiFmWa7J4jpAV+spT+Z8sjEZ/dtgo9OAWyXQv5sGL/Tb8JgOQ02KJ bscF1KtqOv7kGtT3VBhlx2lWmGlB1KzbJ/qsteF45rLuwqWT+PR1FvY3p09Kpsh96iKU ehZMqY9CnyVxXwuMVLdXQ2sid+LzHDfMxPCr7Wj+Nwp1HmGe96HPuNe4MkvPpQBSPzAy cpEA/JMUj7261YRzgfm65Rq5JqyWBJ0ArvoMDXYQkJ8NmErag5SV+1wZhaEQMzs9++AX gy3g== X-Gm-Message-State: ACgBeo2OO5HtCQW59ENWZ7R5t8mt9OGYLZAwhnrQgvHaD6Ov1+dKBofw nriHUoEGHcy4LLG9y9TDcDu+idHNUluW0trVFho= X-Google-Smtp-Source: AA6agR7n7DYHM3nnCy3WsU33BTmDevHz36ukTKY/dIEFVwM+0Xllyb5Tl//2wtM9CLs3Zive755sFqin5YU2aVXNPCY= X-Received: by 2002:a05:6512:1527:b0:48b:99:f3ff with SMTP id bq39-20020a056512152700b0048b0099f3ffmr7843690lfb.81.1661221945792; Mon, 22 Aug 2022 19:32:25 -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 10:31:57 +0800 Message-ID: Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited To: Michal Hocko , Suren Baghdasaryan Cc: 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=1661221947; a=rsa-sha256; cv=none; b=Af/f0CMkDnpy658K1VyQ70aLuK4+yvAD3L8tCBQcf85j6zNvgQpdW1Xnw3lhA4eoHtNZzh o7SL+sjXOGjLhvBZihEtT9x4gXEjnNoj0t6YAujkuNcRsLme5qBUQhk1E+rc1vFimjRVKd x0hxQ4J3z4dH4+5gRsB1g98U4/0EWsU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mOKeqhKY; spf=pass (imf18.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.48 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=1661221947; 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=azDpKc6FmKTWyiu0fmvIHIHwLpZTiSK1Vlo7KGhRPTI=; b=NCv10nQI3AaHCn7YJ5+s8FSSa3nuDstS/OGhTj0xiRmPTNX5gj7IDhju0mCw5vNLFL0cyF ICKo6drClErpegBZPlEUccWRURr73LEyFR1Gj1MRXSWMrHS1pZke7RQUwliApV4eMFx6lL bKMsV6KP/EklfsJEPBWeE8R7GJVi18Y= Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mOKeqhKY; spf=pass (imf18.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 872D31C000D X-Stat-Signature: 94ra88i4hdu1t8ftwiykdo1bsudozxeh X-Rspam-User: X-HE-Tag: 1661221947-169393 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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." > > 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. > -- > Michal Hocko > SUSE Labs