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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7399EC433E1 for ; Tue, 2 Jun 2020 20:14:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2AE282074B for ; Tue, 2 Jun 2020 20:14:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="mYowgcv9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AE282074B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD02380053; Tue, 2 Jun 2020 16:14:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B59C680052; Tue, 2 Jun 2020 16:14:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A481B80053; Tue, 2 Jun 2020 16:14:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 86F6980052 for ; Tue, 2 Jun 2020 16:14:29 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 56472181AEF00 for ; Tue, 2 Jun 2020 20:14:29 +0000 (UTC) X-FDA: 76885374258.11.store99_7e70046576b2e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 2BD85180F8B82 for ; Tue, 2 Jun 2020 20:14:29 +0000 (UTC) X-HE-Tag: store99_7e70046576b2e X-Filterd-Recvd-Size: 3944 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Jun 2020 20:14:28 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B50F1207D5; Tue, 2 Jun 2020 20:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591128868; bh=82d8IPH1EquqiCBgRHSpaeD3CuNcwsT0ccr8uH1l4Ls=; h=Date:From:To:Subject:In-Reply-To:From; b=mYowgcv9K87+/VGdcBcysdw/z+oSMVkvfTs2jWFDnBA0dTmaS61NXjyoj4VlK60mJ +Pb4ptGRfx5PGT2rr8vRkZsJS3TxxYXVIwkxTep2MWDt0JDT7uEPiuRTDwaCK2t5Pd 5fYCMNSKN7P35wjF7Ce9N7fcrL43+Pzp5Yp6VnFA= Date: Tue, 02 Jun 2020 13:14:27 -0700 From: Andrew Morton To: akpm@linux-foundation.org, chris@chrisdown.name, guro@fb.com, hannes@cmpxchg.org, laoar.shao@gmail.com, linux-mm@kvack.org, mgorman@suse.de, mhocko@kernel.org, mm-commits@vger.kernel.org, shakeelb@google.com, torvalds@linux-foundation.org Subject: [patch 078/128] memcg: expose root cgroup's memory.stat Message-ID: <20200602201427.Hl61xsVVf%akpm@linux-foundation.org> In-Reply-To: <20200602130930.8e8f10fa6f19e3766e70921f@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 2BD85180F8B82 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: From: Shakeel Butt Subject: memcg: expose root cgroup's memory.stat One way to measure the efficiency of memory reclaim is to look at the ratio (pgscan+pfrefill)/pgsteal. However at the moment these stats are not updated consistently at the system level and the ratio of these are not very meaningful. The pgsteal and pgscan are updated for only global reclaim while pgrefill gets updated for global as well as cgroup reclaim. Please note that this difference is only for system level vmstats. The cgroup stats returned by memory.stat are actually consistent. The cgroup's pgsteal contains number of reclaimed pages for global as well as cgroup reclaim. So, one way to get the system level stats is to get these stats from root's memory.stat, so, expose memory.stat for the root cgroup. from Johannes Weiner: There are subtle differences between /proc/vmstat and memory.stat, and cgroup-aware code that wants to watch the full hierarchy currently has to know about these intricacies and translate semantics back and forth. Generally having the fully recursive memory.stat at the root level could help a broader range of usecases. Why not fix the stats by including both the global and cgroup reclaim activity instead of exposing root cgroup's memory.stat? The reason is the benefit of having metrics exposing the activity that happens purely due to machine capacity rather than localized activity that happens due to the limits throughout the cgroup tree. Additionally there are userspace tools like sysstat(sar) which reads these stats to inform about the system level reclaim activity. So, we should not break such use-cases. Link: http://lkml.kernel.org/r/20200508170630.94406-1-shakeelb@google.com Signed-off-by: Shakeel Butt Suggested-by: Johannes Weiner Acked-by: Johannes Weiner Acked-by: Yafang Shao Acked-by: Chris Down Cc: Mel Gorman Cc: Roman Gushchin Cc: Michal Hocko Signed-off-by: Andrew Morton --- mm/memcontrol.c | 1 - 1 file changed, 1 deletion(-) --- a/mm/memcontrol.c~memcg-expose-root-cgroups-memorystat +++ a/mm/memcontrol.c @@ -6228,7 +6228,6 @@ static struct cftype memory_files[] = { }, { .name = "stat", - .flags = CFTYPE_NOT_ON_ROOT, .seq_show = memory_stat_show, }, { _