Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1176143iob; Thu, 28 Apr 2022 22:11:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxAYhTXLvMBpSAxdG7wZgM9dlEasxZA9m8dSJpqagjP/r5qOLAZ6PDbBFwy8xtZUcn+AnR4 X-Received: by 2002:a05:6512:139f:b0:44b:36e:b50f with SMTP id p31-20020a056512139f00b0044b036eb50fmr26206529lfa.594.1651209104615; Thu, 28 Apr 2022 22:11:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651209104; cv=none; d=google.com; s=arc-20160816; b=WFNFKHRf/ga71DsdNcAgRiyrWXYdi6zq89UGhYdNW/BdN9FG2j3Ec4lPw7GZryWyvY XUNRcvCmPImr6B20iPYoTXuFVQq4cyG7nS1iy5xahAC31lq6VKd3mMEs0OKrTz/PxSWm V/55xHJhABQOAQ1avtx7oTgmvuWLMMKn/HbsBdXo4krV08GENxZDNwfimCXNpUnT2LMH kyhN6+s/HafYV2/U4Aem1JSGDgevpq0V06jkA1KPE8+6AIJKmk4ffadKozTt5AmV6zgV VpP1xiJoNdypIt8mM8XN8QPGiJgo8mooSCudzkJXeCkG9ZAbh2w1wWd1J9Nhhv+WZF5e JA4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9SmhuH9L8EteTfK00zaW2y4ppXf8qMlwYgDRccWGmt8=; b=iV1TWa3jEwD7x6mP6V8DZA1xHM/+z6xUKYhHSxZ5q9i1XLRN8JOxFMei0FoRvgEQme msV87sHu2wJJ2/ITKQkzFHq2z7uxJfSmFXvk8uSxvHkHWkiThwZ2cx0ubb6uFGAsm+6B NVs6j0j7d1sK/t1BUNe6LPpIZW1VnD2WbHCcngKYl2XQbxszLQgMsSjoMZ6bjygCrFp1 RlusK7IRevCuTrW3UI+9hveDvM/O7ccQ3VhOCmqnlQB4y1CafvwbfKJBaWPUoXuFN5ND 4kVMeuN3NTThRtbr0MET8+8N0FsNhQp7c374SX23XmT8qN3hEzRAMfktyYTRYtCoYj9y uM9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=muYbbgHf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d18-20020a05651233d200b0046b905f1911si6577554lfg.201.2022.04.28.22.11.07; Thu, 28 Apr 2022 22:11:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=muYbbgHf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346038AbiD1R1U (ORCPT + 99 others); Thu, 28 Apr 2022 13:27:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239066AbiD1R1O (ORCPT ); Thu, 28 Apr 2022 13:27:14 -0400 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A17095BE5A for ; Thu, 28 Apr 2022 10:23:58 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id o18so3985314qtk.7 for ; Thu, 28 Apr 2022 10:23:58 -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=9SmhuH9L8EteTfK00zaW2y4ppXf8qMlwYgDRccWGmt8=; b=muYbbgHfo9WGJ1lQRYahawpH/mrMNBfK7mzuL6u28IeAbj+iYGwzrcpKpmnim+KBUZ 5zkJFG9NzPq3+fKpOGZOAOCrXhf1wnatHjmKIAJUsMQs5U0pugjuVBY2Z7AgfvG4w+UV GwUMTlFqZrpnjMRWFeuK056BahnHxRCPKIVERaYT1ttVL6koUM8tI9eLPPI8y6nh9S2h MsMQWashOIjoU1ALQwCGF9oKu1uSxRIMYVl11VzzxDSKsalcUzJEheKrtsHyEtXmJG40 tJ3Xv6dwPjHqkXwnMbRYE8iYiEZDw1H010FE9plnpaCbA12V/gFpErMKMqYXYn3TC5FN UvwA== 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=9SmhuH9L8EteTfK00zaW2y4ppXf8qMlwYgDRccWGmt8=; b=2YiDtusBcgo1M+YjfYez6U8VFw/r3PZkdpnP7WQhueIdE0T8nU3CS1lmS9ZVKfAsbY TFYFcDDMKR4irbquGljrYdZ1/xnx8sPJabxzEMmoE/zO8BkJB3FEINRroEcrlHEoNMAU jqVbZkZ+Onq+fV0ZcSYDcw+rVa5hIltY9tJwziDaKHgoq6ANwHQqTrMek1wukxDokHYk /uCbICVTeEbETCEKQld10pg8GwzXcetKbyv+mTbqiHKTOTcw01Fr1vewrco7q4zClSlo Gwx82BFi3HG3XMlHzbIWS3ROjahXpXK/z+mIwmdECwgTDUFEieEOlEib4fB41flEg7Rw R+5A== X-Gm-Message-State: AOAM530/94rU7b8vd/6E66oeWwNoBLw2hHQl0NLDr6OovanjS/heSDgS ONup1bk6/BJdBxW/VRqF0gneHQ== X-Received: by 2002:ac8:6ce:0:b0:2f0:29dd:bbc5 with SMTP id j14-20020ac806ce000000b002f029ddbbc5mr24591969qth.216.1651166637780; Thu, 28 Apr 2022 10:23:57 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:d588]) by smtp.gmail.com with ESMTPSA id y13-20020a05622a164d00b002f1ff52c518sm337931qtj.28.2022.04.28.10.23.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 10:23:57 -0700 (PDT) Date: Thu, 28 Apr 2022 13:23:21 -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: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? What I'm more worried about is the fact that in theory you can stack zswap on top of zram. Consider a fast compression cache on top of a higher compression backend. Is somebody doing this now? I doubt it. But as people look into memory tiering more and more, this doesn't sound entirely implausible. If the stacked layers then share the same in/out events, it would be quite confusing. If you think PSWPIN/OUT and per-device stats aren't enough, I'm not opposed to adding zramin/out to /proc/vmstat as well. I think we're less worried there than with /proc/meminfo. I'd just prefer to keep them separate from the zswap events. Does that sound reasonable?