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 065A9C32772 for ; Tue, 23 Aug 2022 08:33:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DDEA6B0074; Tue, 23 Aug 2022 04:33:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78DAF8D0002; Tue, 23 Aug 2022 04:33:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62DC56B0078; Tue, 23 Aug 2022 04:33:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 538CE6B0074 for ; Tue, 23 Aug 2022 04:33:39 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2244012147A for ; Tue, 23 Aug 2022 08:33:39 +0000 (UTC) X-FDA: 79830193758.26.98B6BAD Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf31.hostedemail.com (Postfix) with ESMTP id 9DE2B20047 for ; Tue, 23 Aug 2022 08:33:38 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7A80020EFF; Tue, 23 Aug 2022 08:33:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661243617; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JXhtiVs1Pea0+3tSyFvIt2OFwCvUnOkhvBpBR3hLHJ0=; b=itIsnssHRKDHR9XCvqruAA80oSf8XNyabWsyTGumPDHDXGN9IEy42MmKzZi7rYCqRALpUy anrc2/ssKuHRWVtuu0qrWAxP8cCFlfwjJKBTlxdsmpO0ESwlj3fToH3WoPcL+5pXSPOu2e Jtss8aiqbHbTvHKhu+P2bl7GijmoUo0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 5E8B013A89; Tue, 23 Aug 2022 08:33:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id HnZcFuGQBGPeWAAAMHmgww (envelope-from ); Tue, 23 Aug 2022 08:33:37 +0000 Date: Tue, 23 Aug 2022 10:33:36 +0200 From: Michal Hocko To: Zhaoyang Huang Cc: Suren Baghdasaryan , Tejun Heo , Shakeel Butt , "zhaoyang.huang" , Johannes Weiner , Linux MM , LKML , Cgroups , Ke Wang , Zefan Li , Roman Gushchin , Muchun Song Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited Message-ID: References: <1660908562-17409-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661243618; a=rsa-sha256; cv=none; b=dgwj7h6Il4dnEGNlmuS84s8Z6++x2X5j+xmiiZINMnNoMSwGFIJ0t2QAyvar4X4jv3i6Ky +lHOsnW70iyLWcA/EPAD4uk9L7B5lqT7Xe0GZQgsYlqj/TIrdi5Cgn641U5+4bV9R5eOFd 1qfDuQue7WfaYcsi7NgktVq2pby1G5g= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=itIsnssH; spf=pass (imf31.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661243618; 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=JXhtiVs1Pea0+3tSyFvIt2OFwCvUnOkhvBpBR3hLHJ0=; b=gzYsOfg0acbuzziBjBWrriE5Rh9Z5d8kgFZhH+vcue87vHphgzuXs7fq8U2ajW/Z6E19cw 5iHEQicntbXqXxnUT6IV5y/MHeKksP+n101hwQq7tZ6E9m8GScG6WJhKi2bbPHIeLvUzxE +LNKuP0E/7L/wE5230hVT7bRjZkk1Ks= X-Stat-Signature: uyphkgffhgw7aahmadssue8hpycsardk X-Rspamd-Queue-Id: 9DE2B20047 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=itIsnssH; spf=pass (imf31.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1661243618-609831 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 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? > > > > 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 = "" 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. 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 = "")? 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. -- Michal Hocko SUSE Labs