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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 8191BC28CBC for ; Sat, 9 May 2020 14:06:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1915C2184D for ; Sat, 9 May 2020 14:06:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CPCRxhMf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1915C2184D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B2EBF900006; Sat, 9 May 2020 10:06:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADF298E0003; Sat, 9 May 2020 10:06:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1D10900006; Sat, 9 May 2020 10:06:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 87C2A8E0003 for ; Sat, 9 May 2020 10:06:52 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3AA9B49960C for ; Sat, 9 May 2020 14:06:52 +0000 (UTC) X-FDA: 76797356664.01.brush43_1ed90f2336b20 X-HE-Tag: brush43_1ed90f2336b20 X-Filterd-Recvd-Size: 5137 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 May 2020 14:06:51 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id h26so3695961lfg.6 for ; Sat, 09 May 2020 07:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i3sW6gGxSFYLbQMqiE2OgOKIm35ARKyWWruHIK3w6PQ=; b=CPCRxhMfKQFuwDgy/ZmcW/xhfqV9MdzE0YYS6RcYSPljXI+g3UHNduR7qxy2YGhc02 GoaSSHkPldIsQRT8xbeolWkO3usdS1kv3Dhxp0Ca4hBTTQrWvNsZJuNkYkZLVpuXFoB8 oI8WDKM34ouq9Js46hM3qWS8zrhxK2DBmWc9mPr/tqH1XX5lNSnvx6Yvw+vTiuNiFV2U Z+p5NLf4IIdQ4G5rPcYJbwweK01tArCoId4O6qFw7jvLqx2MJ87hZaMXC9WrTuzzQAXY OdOS/3YRXvUFDzEYQlGiyGA/TdrvopOsFm+IJyLwCx+BAU+35ZByFSjxEAknOiwmj5Yv E+kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i3sW6gGxSFYLbQMqiE2OgOKIm35ARKyWWruHIK3w6PQ=; b=YJh7ln1CzkNu7F6p/87oUeQcr4CY6H9Rz6ORvL0Dp6wt2w9q2ICPzU3Tcuff0JLVjo ZBUwArEl8hZeENmyVVQNhqqnHAhgkr7nMCC8drujnGmT4CFcXQJ1xbkjnRKfu7EVOnjo xjvfSS7B+ciomvoEnwaJD+q0O+DdhfXWfN9jwpQKi96YtRXLXHplffbE6+iIhbx6PRw/ Wwh7x3+i/L1zS0cDW1e8XypjiHjptPdtc4B9/kUzPuUMfzVyhjO8T03AJoZhNXWAVjBZ Lz7LqGi/0mEPh+cLeGK2rsrJ3SzQS7t+SzgBzWPigv7ZU2/MR/K4/BZ/eprsBtBpeWx5 nZXw== X-Gm-Message-State: AOAM531bI1UyyZE7PQOFWLfUkJAZDmPJp6hnaHstlu7kqw2UQTBYoefz ihMlvKIE/bPNNGzV/fyqJOJAyV1MnQiQclTe/Jqy5g== X-Google-Smtp-Source: ABdhPJyWWhFBVG4eHjWySAi6pwQCblm+7itP1oOjJ6xL2tX+stPpmpIqFW5098YtOuNnNxwD27REHPC+dSfHiPA65c0= X-Received: by 2002:a19:ee19:: with SMTP id g25mr5288736lfb.124.1589033209912; Sat, 09 May 2020 07:06:49 -0700 (PDT) MIME-Version: 1.0 References: <20200508170630.94406-1-shakeelb@google.com> <20200508214405.GA226164@cmpxchg.org> In-Reply-To: <20200508214405.GA226164@cmpxchg.org> From: Shakeel Butt Date: Sat, 9 May 2020 07:06:38 -0700 Message-ID: Subject: Re: [PATCH] memcg: expose root cgroup's memory.stat To: Johannes Weiner Cc: Mel Gorman , Roman Gushchin , Michal Hocko , Andrew Morton , Yafang Shao , Linux MM , Cgroups , LKML Content-Type: text/plain; charset="UTF-8" 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 Fri, May 8, 2020 at 2:44 PM Johannes Weiner wrote: > > On Fri, May 08, 2020 at 10:06:30AM -0700, Shakeel Butt wrote: > > 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. > > The changelog begs the question why we don't just "fix" the > system-level stats. It may be useful to include the conclusions from > that discussion, and why there is value in keeping the stats this way. > Right. Andrew, can you please add the following para to the changelog? 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. > > Signed-off-by: Shakeel Butt > > Suggested-by: Johannes Weiner > > Acked-by: Johannes Weiner Thanks a lot.