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 43002C433F5 for ; Wed, 10 Nov 2021 19:11:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFD80610FC for ; Wed, 10 Nov 2021 19:11:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EFD80610FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 689216B006C; Wed, 10 Nov 2021 14:11:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 637886B0071; Wed, 10 Nov 2021 14:11:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 526916B0072; Wed, 10 Nov 2021 14:11:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 42A8C6B006C for ; Wed, 10 Nov 2021 14:11:30 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0495982CCB97 for ; Wed, 10 Nov 2021 19:11:30 +0000 (UTC) X-FDA: 78793964340.04.EC0149D Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 69E3E7001706 for ; Wed, 10 Nov 2021 19:11:23 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id 188so3084572pgb.7 for ; Wed, 10 Nov 2021 11:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OqyzeCyoCvvYPV9DVCrFvaqu6R57AheLr6xAlpsogPI=; b=GFs9WOfYWUEgxxeQ4/2M8fM0pX/gUu7eNkTskOt/SgCSPfUU3nXMgs3iIxvUpraxgA lOudnZhmHbTM/WVo52+3xoc3EzUWXuWuuuBKH+5qnchVs+3jtYygzDhZwlzlEMXyKYX/ AF3ipfHBwexMnz7NhaPy2SmxJDrqXY3o3aW+ijoLh2WuGD+W1kpXSyq1Wu4cQImznzFu Wzf4uhM9W0pGgOXzXw7pXhksvYJLXgZSmntZmisqkh0KVCLyDXLVEh8+jKib+TlQgPjH wZ9E4wDAKmZxcpKf9mUyxPl1h7lJdnIYSNB6IP5++BvSrgNDqJGCHrApxGOH4afsdBSL XTSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=OqyzeCyoCvvYPV9DVCrFvaqu6R57AheLr6xAlpsogPI=; b=ndZiawT9tRZRMdQIveI/n/Tn8iN8aDpzBI1rvGdrUpn/QiVB7kTQtUWuk4Zw87TXdN XU9UqbqQQrBLhIIG0shOi6l/zJQgv55pjzuIr0qK0yE0ny11B02vc7wHYu21R5hZCbxE q88n3XlcaPT3iN1/7sm1t/YHqBy2UVVAR6+JPBhHQ7tH08H1IqnDXO+UdRgLBQ+ceBKp DrTnyb0ymNXS/kEc1y6bIbggU2baG8mGVbOlFamTVUZicwMKAdMBx5pozaTn1tNJONGa qqX2QMB+bLU3U1NfrZPOaEVe+gWaFgxftfW23VcZ7JiQTMjzZq9EbajhN6eBN5sC3HWd dvZw== X-Gm-Message-State: AOAM530wva+CgCFB0SXQu9jfUiZJoK2/3Asc+PlmIJ1J3HOmzwqumhGd SOFaZICUQDHvm4fYRf9snE0= X-Google-Smtp-Source: ABdhPJy3AVp4RRoT7gNVI7XlIFa4jVj+kqj6mCpMofJK/hurnGRFW8fZdgsAQ0MmQjfGP8ekK/DESw== X-Received: by 2002:a05:6a00:b49:b0:49f:bad2:bd7c with SMTP id p9-20020a056a000b4900b0049fbad2bd7cmr1308709pfo.64.1636571488481; Wed, 10 Nov 2021 11:11:28 -0800 (PST) Received: from google.com ([2620:15c:211:201:11d4:2de3:ab82:be64]) by smtp.gmail.com with ESMTPSA id e15sm397567pfv.131.2021.11.10.11.11.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 11:11:28 -0800 (PST) Date: Wed, 10 Nov 2021 11:11:26 -0800 From: Minchan Kim To: Johannes Weiner 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: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 69E3E7001706 X-Stat-Signature: jg9csxkk33y319wogwkttctya8n4tn9h Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GFs9WOfY; spf=pass (imf02.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-HE-Tag: 1636571483-235743 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 Johannes, On Tue, Nov 02, 2021 at 11:06:17AM -0400, Johannes Weiner wrote: > 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? My view is the the allocators aims to store compressed memory. Likewise slab allocator, we could use the allocator any places and display the total memory usage from the allocator in meminfo instead of each subsystem and look at slabinfo if we need further break down. I think it could work for this case, too. > > I agree zram should probably also have memory counters, but I think it > makes sense to recognize zswap as a unique MM layer. Under your view, I think it would introduce Zram-swap, Zram-block as well as Zswap. If folks think it's better idea, I am fine and happy to post a patch to merge it along with this patch.