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 82791C433EF for ; Thu, 28 Apr 2022 18:35:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4AD96B00EF; Thu, 28 Apr 2022 14:35:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD28F6B00F0; Thu, 28 Apr 2022 14:35:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4C356B00F1; Thu, 28 Apr 2022 14:35:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 9E1BB6B00EF for ; Thu, 28 Apr 2022 14:35:07 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 45C452AEA6 for ; Thu, 28 Apr 2022 18:35:07 +0000 (UTC) X-FDA: 79407139854.25.AE76CBD Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf24.hostedemail.com (Postfix) with ESMTP id 8392918007B for ; Thu, 28 Apr 2022 18:35:02 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id i2so4258426qke.12 for ; Thu, 28 Apr 2022 11:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8ugQMiswQ3FtlNfbd5S1Cs00NrebB6/yQ6qlB0CbEuo=; b=izbzVdnqmdIK+VBGaeAtYzR/4stEUIQ3i/Tzy1/5c4UYIQWW2afku1oa7qX6ptYYbX ujtlmErIsLSRWIoaCYtSOLP6d1a9oXeyUw8m4EvkXplGd2vYDZvJtiuj0x3UBD0C/ur8 qdRqnZnrgu2OKhWFt63OPZ084rWufen4ke6QRR+ndfY1lpfW5QX9gHVCi5Aj5SnlJCIR syhtIXV2zw/Mr3lPQCjjLmGUIkBwoayr639kpy7XCAOlMj5gm73pFbqywUndB5V77qWT bNOz+bGnwiJyh5gynO83kU+KhEy2RwLPyyMJ+rkTED4rBrVxNt+bTs+F0Bvtte96NmOQ Hecw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8ugQMiswQ3FtlNfbd5S1Cs00NrebB6/yQ6qlB0CbEuo=; b=rrMCyLKSkGVprGJMyJ5poK+73edvecXDDyJc4ufruwJDdrXc6quvHipme7LspiWN4x /JfGoBefSRXefUs7yxpIEVvll61jFLpS1vHarBiZW9ItbHNV66qpSF8IkMrn9lohAJB+ V4jA131KKiGvbM6Thml9v+Hl8LlurS/GFKEOL/vF4AAfp7sOHb/j6a5KpOYiP8a65iee kUf8IbRf4Q5+MrxAtzKtjuZzjF2cP+OMj7wGAauo7kd1YzuaHdz4bqbfl44dl6aMmNqW pobS3ECvaugKIeTYn3YBz1m+6Pc4c0oXtN5xDaiK07ljXNfDb24a7XxNNtBRmcDJFgsn tpmA== X-Gm-Message-State: AOAM530ad+GH2pHS9hSYt3t5+tYucGE6gcdPEK65kST/dxo5e80bJwuQ 9RRCmIna52EWs4Zn4lvwugJE/g== X-Google-Smtp-Source: ABdhPJzJLSBxlhNYP8hU3o4notM7XrlTWB3+RyEKfhUd63EyjB+FcZ3NxJckIKkwSVEGpnuShiJkxQ== X-Received: by 2002:a37:9dc9:0:b0:69f:9e56:68ec with SMTP id g192-20020a379dc9000000b0069f9e5668ecmr3395964qke.394.1651170905671; Thu, 28 Apr 2022 11:35:05 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:d588]) by smtp.gmail.com with ESMTPSA id c27-20020ac84e1b000000b002f3851fcac0sm375767qtw.65.2022.04.28.11.35.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 11:35:05 -0700 (PDT) Date: Thu, 28 Apr 2022 14:34:28 -0400 From: Johannes Weiner To: Minchan Kim Cc: Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Seth Jennings , Dan Streetman , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 4/5] mm: zswap: add basic meminfo and vmstat coverage Message-ID: References: <20220427160016.144237-1-hannes@cmpxchg.org> <20220427160016.144237-5-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=izbzVdnq; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8392918007B X-Rspam-User: X-Stat-Signature: 9euykpxy75yqdy98pqbjrcobkppii45b X-HE-Tag: 1651170902-431058 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 Thu, Apr 28, 2022 at 10:31:45AM -0700, Minchan Kim wrote: > On Thu, Apr 28, 2022 at 01:23:21PM -0400, Johannes Weiner wrote: > > On Thu, Apr 28, 2022 at 09:59:53AM -0700, Minchan Kim wrote: > > > On Thu, Apr 28, 2022 at 10:25:59AM -0400, Johannes Weiner wrote: > > > > On Wed, Apr 27, 2022 at 03:16:48PM -0700, Minchan Kim wrote: > > > > > On Wed, Apr 27, 2022 at 05:20:29PM -0400, Johannes Weiner wrote: > > > > > > On Wed, Apr 27, 2022 at 01:29:34PM -0700, Minchan Kim wrote: > > > > > > > Hi Johannes, > > > > > > > > > > > > > > On Wed, Apr 27, 2022 at 12:00:15PM -0400, Johannes Weiner wrote: > > > > > > > > Currently it requires poking at debugfs to figure out the size and > > > > > > > > population of the zswap cache on a host. There are no counters for > > > > > > > > reads and writes against the cache. As a result, it's difficult to > > > > > > > > understand zswap behavior on production systems. > > > > > > > > > > > > > > > > Print zswap memory consumption and how many pages are zswapped out in > > > > > > > > /proc/meminfo. Count zswapouts and zswapins in /proc/vmstat. > > > > > > > > > > > > > > > > Signed-off-by: Johannes Weiner > > > > > > > > --- > > > > > > > > fs/proc/meminfo.c | 7 +++++++ > > > > > > > > include/linux/swap.h | 5 +++++ > > > > > > > > include/linux/vm_event_item.h | 4 ++++ > > > > > > > > mm/vmstat.c | 4 ++++ > > > > > > > > mm/zswap.c | 13 ++++++------- > > > > > > > > 5 files changed, 26 insertions(+), 7 deletions(-) > > > > > > > > > > > > > > > > diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c > > > > > > > > index 6fa761c9cc78..6e89f0e2fd20 100644 > > > > > > > > --- a/fs/proc/meminfo.c > > > > > > > > +++ b/fs/proc/meminfo.c > > > > > > > > @@ -86,6 +86,13 @@ static int meminfo_proc_show(struct seq_file *m, void *v) > > > > > > > > > > > > > > > > show_val_kb(m, "SwapTotal: ", i.totalswap); > > > > > > > > show_val_kb(m, "SwapFree: ", i.freeswap); > > > > > > > > +#ifdef CONFIG_ZSWAP > > > > > > > > + seq_printf(m, "Zswap: %8lu kB\n", > > > > > > > > + (unsigned long)(zswap_pool_total_size >> 10)); > > > > > > > > + seq_printf(m, "Zswapped: %8lu kB\n", > > > > > > > > + (unsigned long)atomic_read(&zswap_stored_pages) << > > > > > > > > + (PAGE_SHIFT - 10)); > > > > > > > > +#endif > > > > > > > > > > > > > > I agree it would be very handy to have the memory consumption in meminfo > > > > > > > > > > > > > > https://lore.kernel.org/all/YYwZXrL3Fu8%2FvLZw@google.com/ > > > > > > > > > > > > > > If we really go this Zswap only metric instead of general term > > > > > > > "Compressed", I'd like to post maybe "Zram:" with same reason > > > > > > > in this patchset. Do you think that's better idea instead of > > > > > > > introducing general term like "Compressed:" or something else? > > > > > > > > > > > > I'm fine with changing it to Compressed. If somebody cares about a > > > > > > more detailed breakdown, we can add Zswap, Zram subsets as needed. > > > > > > > > > > Thanks! Please consider ZSWPIN to rename more general term, too. > > > > > > > > That doesn't make sense to me. > > > > > > > > Zram is a swap backend, its traffic is accounted in PSWPIN/OUT. Zswap > > > > is a writeback cache on top of the swap backend. It has pages > > > > entering, refaulting, and being written back to the swap backend > > > > (PSWPOUT). A zswpout and a zramout are different things. > > > > > > Think about that system has two swap devices (storage + zram). > > > I think it's useful to know how many swap IO comes from zram > > > and rest of them are storage. > > > > Hm, isn't this comparable to having one swap on flash and one swap on > > a rotating disk? /sys/block/*/stat should be able to tell you how > > traffic is distributed, no? > > That raises me a same question. Could you also look at the zswap stat > instead of adding it into vmstat? (If zswap doesn't have the counter, > couldn't we simply add new stat in sysfs?) My point is that for regular swap backends there is already PSWP*. Distinguishing traffic between two swap backends is legitimate of course, but zram is not really special compared to other backends from that POV. It's only special in its memory consumption. zswap *is* special, though. Even though some people use it *like* a swap backend, it's also a cache on top of swap. zswap loads and stores do not show up in PSWP*. And they shouldn't, because in a cache configuration, you still need the separate PSWP* stats to understand cache eviction behavior and cache miss ratio. memory -> zswap is ZSWPOUT; zswap -> disk is PSWPOUT; PSWPIN is a cache miss etc. > I thought the patch aims for exposting statistics to grab easier > using popular meminfo and vmstat and wanted to leverage it for > zram, too. Right. zram and zswap overlap in their functionality and have similar deficits in their stats. Both should be fixed, I'm not opposing that. But IMO we should be careful about conflating them. Fundamentally, one is a block device, the other is an MM-native cache layer that sits on top of block devices. Drawing false equivalencies between them will come back to haunt us.