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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 04C31C433E0 for ; Sat, 16 May 2020 01:42:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A684C2076A for ; Sat, 16 May 2020 01:42:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="AH0puOca" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A684C2076A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 50F0E8E0003; Fri, 15 May 2020 21:42:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BFA28E0001; Fri, 15 May 2020 21:42:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D4078E0003; Fri, 15 May 2020 21:42:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 22B0B8E0001 for ; Fri, 15 May 2020 21:42:50 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD9748248047 for ; Sat, 16 May 2020 01:42:49 +0000 (UTC) X-FDA: 76820883258.07.sleet22_35caa129c0625 X-HE-Tag: sleet22_35caa129c0625 X-Filterd-Recvd-Size: 5085 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Sat, 16 May 2020 01:42:49 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id k13so3397403wrx.3 for ; Fri, 15 May 2020 18:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kS8OYMG072jDcI6wkY/z+PD46Du/tMZhKnhnXKRsoeo=; b=AH0puOca79INHP4Gyjk8o8AyxnmdUlm/s7CIZkXpa4xvSasJLmdH8L2vWT0y+OPoA2 I0dBbUpqu90pgUFRkEbf4DKo2KVJwQ7QIFWnpt9s6w4TNSbgkI5skacNqeGVjFYdGK2v XfuM/QsPsOjBfWclFvjZVsVcN2YdvdcuqqfPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kS8OYMG072jDcI6wkY/z+PD46Du/tMZhKnhnXKRsoeo=; b=QFKTO1iQpAo53wjcomZTt4/s8pLz0wHLVEUgfkxeIr/0KiVCL7uRUP4u8fwP8+1FMs AZx6GmFxFfYuV9DSkkImu52Z1+n3ap7QHd4g6l6lDROSXBF+ZrEFy7/8X1cx5UqgiRn5 B2FNGufTHukIuT0gmgQJZrDgOvwsA9Pw+TdoSNc7MUj2/uIL5xR2nmHJqyXkEmxyVIdO 6mbrJ0o+dsd4XEdmZzm/enS1tA/uEUFHImPWXBSuc53U8Br/tHFrHZm3LS3X2kuaMaMA 7d2bEc5YBvdtO5kEoUxQpqGA7f8Wn/GxNsdPRUeUJQ9MMJEaXDvvxJQLtM7Iha5xN8vf 8Xbg== X-Gm-Message-State: AOAM532TUTQu2kkCVDYs3t42hVNNh7FZHymBrUWZXLUvtfB5morwnnnw 5ajONNbEGBqWm8SULnTDeKphnQ== X-Google-Smtp-Source: ABdhPJygr4YRwvdn5bQj/+FRk7Jk9MpKoXCmkZ5L4Hgg+hvUMxR3NbMw1h1nDwgPO85GahUNXx18VA== X-Received: by 2002:adf:9b91:: with SMTP id d17mr6892266wrc.183.1589593368152; Fri, 15 May 2020 18:42:48 -0700 (PDT) Received: from localhost ([2a01:4b00:8432:8a00:56e1:adff:fe3f:49ed]) by smtp.gmail.com with ESMTPSA id x5sm6315441wro.12.2020.05.15.18.42.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2020 18:42:47 -0700 (PDT) Date: Sat, 16 May 2020 02:42:47 +0100 From: Chris Down To: Shakeel Butt Cc: Mel Gorman , Johannes Weiner , Roman Gushchin , Michal Hocko , Andrew Morton , Yafang Shao , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] memcg: expose root cgroup's memory.stat Message-ID: <20200516014247.GA8578@chrisdown.name> References: <20200508170630.94406-1-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200508170630.94406-1-shakeelb@google.com> 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: Hey Shakeel, Shakeel Butt writes: >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. > >Signed-off-by: Shakeel Butt >Suggested-by: Johannes Weiner The patch looks great, thanks. To that extent you can add my ack: Acked-by: Chris Down One concern about the API now exposed, though: to a new cgroup v2 user this looks fairly dodgy as a sole stat file (except for cgroup.stat) at the root. If I used cgroup v2 for the first time and only saw memory.stat and cgroup.stat there, but for some reason io.stat and cpu.stat are not available at the root but are available everywhere else, I think my first thought would be that the cgroup v2 developers must have been on some strong stuff when they came up with this ;-) Even if they're only really duplicating information available elsewhere right now, have you considered exposing the rest of the stat files as well so that the API maintains a bit more consistency? As a bonus, that also means userspace applications can parse in the same way from the root down.