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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75919C433EF for ; Tue, 2 Nov 2021 15:06:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC81360EB4 for ; Tue, 2 Nov 2021 15:06:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EC81360EB4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3E6D86B006C; Tue, 2 Nov 2021 11:06:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3963B6B0071; Tue, 2 Nov 2021 11:06:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2853D940009; Tue, 2 Nov 2021 11:06:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 167D26B006C for ; Tue, 2 Nov 2021 11:06:21 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C2BCE1844C504 for ; Tue, 2 Nov 2021 15:06:20 +0000 (UTC) X-FDA: 78764316120.21.6EBFE5E Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf03.hostedemail.com (Postfix) with ESMTP id 11E9A30000BC for ; Tue, 2 Nov 2021 15:06:13 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id o12so8354194qtv.4 for ; Tue, 02 Nov 2021 08:06:19 -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=VroI1JUj2TTWzELMwXyHiZqn8NIRBkFCrP9dHy/2068=; b=TdTfAWEhPGmwY1t5Tz+OjaidTjXzVu37QuKGZvyzGdFPsPQ68kgut5D6vTETHd89zE AimP2YcrxRLRuErNCczADVkRGj46k9i6XAe3eHyYE5vAMDKxjRarMr/FmPAYfSzwhXIU wASX/WagNYKc6SskYHXWgYWOf2wQ68qiDNZULOWAzsKePq48elWgb2xIo+PYJiVJYV9P AACN5g54KbpWXPNtu56dqsgVAWgzk/xF2ji2xrj60KmR6v8yKlBlNBrXcCe1noDQzveV BOsfPaO8/txKri8C82ynqyDVRqLkJ0NGDGG/rXToBWpN6tZITiNZIUKDO3YHi2UfX7Mt LgZg== 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=VroI1JUj2TTWzELMwXyHiZqn8NIRBkFCrP9dHy/2068=; b=TE07pcK3clEBG8BfMisB274SHXVSKKzDZYBX6PxMaZEMgyEPX9hErc8kKcEaPvz84f E1LkQJq9IhiSMZUHS46NydJZZNASGo686Hj+NTdJVaZRmhJx4LIcsuWny0zonNCtMrEg AT4LB4OtFbKpxksJeKWer7t1nTEGIi1MX2HvbKsf6qunIeiw2cOPRH03pg0NzMtBMG1v TZlRpmqyooTNjwY5E8bbYeFmWlwY4hdf4Aa9xQEBDlnU6P33DAqzV8apy7Z6D3wc2ys4 2mQ8uopP5KSY1ZQhosLS4jvlgl+4whgqvrVz7joxr8YMhEbE8IRs6WmIRH5nnyrS1YR4 OJag== X-Gm-Message-State: AOAM5312FAunKXIefyw52/yOv0XWPumgUUrPr5p1EdHWe3lbU+vGnaSY hJVunB/YQJAWh8M7e5K8TNWdtA== X-Google-Smtp-Source: ABdhPJxVUzgtID5bD2MMMjfb3b3MU1mwCq6h2NmHyS9aw+r9gLXRj8h6riewjH8XjvjTkse+w0rJig== X-Received: by 2002:ac8:7dcb:: with SMTP id c11mr38510553qte.12.1635865579154; Tue, 02 Nov 2021 08:06:19 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id h14sm8386099qth.23.2021.11.02.08.06.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 08:06:18 -0700 (PDT) Date: Tue, 2 Nov 2021 11:06:17 -0400 From: Johannes Weiner To: Minchan Kim Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 4/4] mm: zswap: add basic meminfo and vmstat coverage Message-ID: References: <20210819195533.211756-1-hannes@cmpxchg.org> <20210819195533.211756-4-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=TdTfAWEh; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam03 X-Stat-Signature: 4k3zoha1yyox6uust9dx6bjndgei7syo X-Rspamd-Queue-Id: 11E9A30000BC X-HE-Tag: 1635865573-253733 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: Hi Minchan, Sorry about the delay, I'm just now getting back to these patches. On Mon, Aug 30, 2021 at 11:49:59AM -0700, Minchan Kim wrote: > Hi Johannes, > > On Thu, Aug 19, 2021 at 03:55:33PM -0400, Johannes Weiner wrote: > > Currently it requires poking at debugfs to figure out the size of the > > zswap cache size on a host. There are no counters for reads and writes > > against the cache. This makes it difficult to understand behavior on > > production systems. > > > > Print zswap memory consumption in /proc/meminfo, count zswapouts and > > zswapins in /proc/vmstat. > > > > Signed-off-by: Johannes Weiner > > --- > > fs/proc/meminfo.c | 4 ++++ > > include/linux/swap.h | 4 ++++ > > include/linux/vm_event_item.h | 4 ++++ > > mm/vmstat.c | 4 ++++ > > mm/zswap.c | 11 +++++------ > > 5 files changed, 21 insertions(+), 6 deletions(-) > > > > diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c > > index 6fa761c9cc78..2dc474940691 100644 > > --- a/fs/proc/meminfo.c > > +++ b/fs/proc/meminfo.c > > @@ -86,6 +86,10 @@ 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)); > > Since we have zram as well as zswap, it would be great if > we can abstract both at once without introducing another > "Zram: " stuff in meminfo. A note: zram can support fs based on > on zram blk device as well as swap. Thus, term would be better > to say "compressed" rather than "swap". > > How about this? > > "Compressed: xx kB" Wouldn't it make more sense to keep separate counters? Zswap and zram are quite different from each other. >From an MM perspective, zram is an opaque storage backend. zswap OTOH is an explicit MM cache stage which may in the future make different decisions than zram, be integrated into vmscan's LRU hierarchy etc. And in theory, you could put zswap with fast compression in front of a zram device with denser compression, right? I agree zram should probably also have memory counters, but I think it makes sense to recognize zswap as a unique MM layer.