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 CAAD0C52D7F for ; Wed, 14 Aug 2024 07:48:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C2316B0088; Wed, 14 Aug 2024 03:48:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4734C6B008A; Wed, 14 Aug 2024 03:48:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3626D6B0092; Wed, 14 Aug 2024 03:48:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 18E2A6B0088 for ; Wed, 14 Aug 2024 03:48:52 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B384EA0CD2 for ; Wed, 14 Aug 2024 07:48:51 +0000 (UTC) X-FDA: 82450074462.08.D1F310A Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf30.hostedemail.com (Postfix) with ESMTP id E334280017 for ; Wed, 14 Aug 2024 07:48:49 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hOnzQOYv; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723621693; a=rsa-sha256; cv=none; b=c5jQdvusVy6fmxmlG5F2hbvGdEH8bPhDZUZrZRE6pqy6NYCcBrWO9XNJ2b5iblvouKCLlz yTwsIa3HoRoKdXewVl1nH5Bhz4kW2Fck21/J21rRvU31PiZSrMCxvgEJxwDgNJgMu3Z1UD uSvjznDNnl1KoMpEsA9TDbNBapcSEs4= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hOnzQOYv; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723621693; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2/wdavvpDC6LcqHnopC8nbqO8FTC/ahoEI/o+/GeLiI=; b=TjbKtIylAOo6RqakVgMWD7RvpZ0Foh60rGy4+QkE9Ib0xv7/RCCDdRrOZR7E++hSh2Rq6F BJz50CBwwyyG7FvRYLAGZDcFHmwzqsH5zIRo8ggkCYqBmUpZ8GHpvWZ7qibjUnhmgFWMiD G8hrRPhfkxor5gZD7HQprGHnPBP1Fxs= Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-4f8b5e4c631so2484425e0c.1 for ; Wed, 14 Aug 2024 00:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723621729; x=1724226529; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2/wdavvpDC6LcqHnopC8nbqO8FTC/ahoEI/o+/GeLiI=; b=hOnzQOYvxf4ZIosXDSKOeAcJVSLGdt9B18OrVvS1aIdLLB+OvYvFZwkPs18aouArXx WBqJwszV89nT5SBOTGHY0NUqZMIFhTCVVgLQ31+xJWSXdtGotNSZnSL/d2FB5uPFDWWA e7Adrp52d64NraLnTRRLP9skAaeAz7UGSS1Ycpz1ocg0jBJrtKv+PTmTbqDmnRaKJhy0 qWMjYrR2uwjuhQ1Anh7hO3gS6VUipVaGB93EYBd/m4+GAEUcri1fz0BJx+fQd7XW4wjM YeQU3GtTlMVdXwNtoS8J7S6Cy01NBSW6zhT5B/Y7HSDcVVYUNFUs+cZ3kXShL1bu2x5+ +SWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723621729; x=1724226529; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2/wdavvpDC6LcqHnopC8nbqO8FTC/ahoEI/o+/GeLiI=; b=twi6AXAuXQ1rC+6Q4vOgpn2FFB62ogVZl5rP9pFT7j3g5fpst6gm8qizjB3gKzK7nv zR3lsPTuefhTJvW6feEX3dSUBMTFYEPakRo/DAcm6y7qVBCW2JaC+MlGHc15O/T2/KUh k3Z6lYiZ/3v1JfmPpp9gwSsiQUUJb4yG/1Jh+vy5m7qdHqfKzYWzICJN3GTvMvAxzuHc HtBwDxnIIikgvCcrU6gHHCDYnGjyOfGtP2mp4Nnq7bCstFeQcrfe2TCfm66GCTefzrsw yh9nj7GyfImANO/mxooeL97CDt/AJLbW/sZM7THPdwAuZ9WvRDp4BD60m4I96f/XP87J egnQ== X-Forwarded-Encrypted: i=1; AJvYcCVbRBcGRuctNBOnw1ZbVpsxAMXEJF92vWYHCqwTeI2mDIzWljHJ12TWWi6L/L3hS1QDcEBSLU79iBbkd8MI6/hv1tY= X-Gm-Message-State: AOJu0YwE3eUlFjQUIVvC+a+RIa5vwVw6BbGlOINR8Apl5yqVj301W2O5 cF38raRRjS//by+OlWnQURrqW3im3JWDBkdM8jom/5AKpoj3v3soCOPbTvxeMKyRInzH9pIjl8X qaaQWGsxPHtM18RYF65UaVyBOt6JBNyib X-Google-Smtp-Source: AGHT+IEd3u4Se6fhBEJdd+aYxIvEQnUcxk3LNnsHSN+HNVOu12kUacMSFGxoST5ZwSx72QX0tMd0YsxEaFAmyfuOAxs= X-Received: by 2002:a05:6122:411e:b0:4f5:2960:6ca6 with SMTP id 71dfb90a1353d-4fad1c2e388mr2546780e0c.2.1723621728923; Wed, 14 Aug 2024 00:48:48 -0700 (PDT) MIME-Version: 1.0 References: <20240814062830.26833-1-kanchana.p.sridhar@intel.com> <20240814062830.26833-3-kanchana.p.sridhar@intel.com> In-Reply-To: <20240814062830.26833-3-kanchana.p.sridhar@intel.com> From: Barry Song <21cnbao@gmail.com> Date: Wed, 14 Aug 2024 19:48:37 +1200 Message-ID: Subject: Re: [RFC PATCH v1 2/4] mm: vmstat: Per mTHP-size zswap_store vmstat event counters. To: Kanchana P Sridhar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, yosryahmed@google.com, nphamcs@gmail.com, ryan.roberts@arm.com, ying.huang@intel.com, akpm@linux-foundation.org, nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: n59dmoct6hccmfo3hgq468biq56fw9fr X-Rspamd-Queue-Id: E334280017 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1723621729-960819 X-HE-Meta: U2FsdGVkX18xdyQHTZYbjT8OZmt/JGtfYkULfEi2sVJ+Ni5kRKG4WcdvNClBvF5tfiJ6+aHqnsF//K3WdUz2Cp5ZrMpGm4C3cfHb8KcBRFlyIBYEdGc8NQTae3R2MU3cDRS5VJeGDjej4JKcLckiRP16gYh+MlaP8Ew5AbqJ/pFSmH89YgqmhGRR9aVfSstLxsOZLbpNlccKbbqOfBgWFmuq/KRhfY6pV8Gam3YKaPT8WkH5s8I3cvR9Q7yLLXNj7jOZvQD1LFrZlAn95zuufi8GZh50p0I7pjd0HDTXmerDfLLEXlE+2QdTpYXZLVe0T1BekmwgtNIF8tOviHCl92d5gb0tCnBkj7Kfimx0Xev+LsZ8b5FSc2VAioes92wXUi5qZtfHTNOXXrCQDCusKm/KeDtHN34WJhsft1G57bNKoGnKupRk5Jn80vfrH1Ffi8A5P5JELvsoXHG1gshuG8LfbOmqV/6IaSp4hUDPZnL7nudOUGdJP+CBdUcdBmdMMuS8Y26YBJWtG2MNsTtu9Te/aMf6v5HUj/jsnpJYyODWErqtTWfcokiCQWVgJKZsx9mcCzVx3LkbSFhL6c9K4JXNSok24Dl5rMSMRtQoDQh2B5j6//gxBSm0yIKrhDKvajwX/xd9gvsTZgbRmV9TKdmbR90tvUkJxVPtv/ICoO8sb1Xq5he3KZ+HgmU4b/9tvpSY806bpP/rrJJUwKcJ/O/2CVj3DG/7Yf/DPN3x1KrnIGkr9BlM0LJYxmgl8MF8XjCwZWiqPaEs6C+7NeUstzWpCBrj1B6B6+zzpyXCJrxIrrpw61dohdXwyA9q4qmA7wKK1VucMoGPFUvOh0hJklOH/l88c9XjwBgqB9x5T0Ah+TCR37VZd69WQtIbVk5AGaekpEbbJ57g5AnZPe0ZtOlmjkyL2xGPJgZVMujtjgjXxEcUflj479iW0Zs1h1JAiQ1zzFevWXfEAUpSccJ 1X103bVm MzgkppWxvzojv3q9SRSkt9QWTLutXlwHI5rtHEf2j9BcWtwpTzMovOQUI+alHwmhZi/2BlWoovT8CsTxK51TWn7WeCxpL34s+3GiDGTlO42WSyMMWCArvSUDGmksKuz/B9qyuKpPVeBubnzh5AYh5leY0kxfH17O4wUzEsG5+degzuJxijUOGxu6v2VVIUSQy2PyrlEyEKB46GSRJCroDA6nv+9B9ozeatj24uJFOUVsLq1cyeDhPP+/UfGQcaFkOk24ibBoGzIKEfvUxcZYAtA3ScAPysN3EgGYKqZsI4hYwttVMjn/aFAoW884nqtTpiikKypudqYdau0LHOjJ0xqX3py9VeAimtKGA72+nvrH88TWe42X0wQ8wfw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Aug 14, 2024 at 6:28=E2=80=AFPM Kanchana P Sridhar wrote: > > Added vmstat event counters per mTHP-size that can be used to account > for folios of different sizes being successfully stored in ZSWAP. > > For this RFC, it is not clear if these zswpout counters should instead > be added as part of the existing mTHP stats in > /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats. > > The following is also a viable option, should it make better sense, > for instance, as: > > /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/zswpout. > > If so, we would be able to distinguish between mTHP zswap and > non-zswap swapouts through: > > /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/zswpout > > and > > /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/swpout > > respectively. > > Comments would be appreciated as to which approach is preferable. Even though swapout might go through zswap, from the perspective of the mm core, it shouldn't be aware of that. Shouldn't zswpout be part of swpout? Why are they separate? no matter if a mTHP has been put in zswap, it has been swapped-out to mm-core? No? > > Signed-off-by: Kanchana P Sridhar > --- > include/linux/vm_event_item.h | 15 +++++++++++++++ > mm/vmstat.c | 15 +++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.= h > index 747943bc8cc2..2451bcfcf05c 100644 > --- a/include/linux/vm_event_item.h > +++ b/include/linux/vm_event_item.h > @@ -114,6 +114,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT= , > THP_ZERO_PAGE_ALLOC, > THP_ZERO_PAGE_ALLOC_FAILED, > THP_SWPOUT, > +#ifdef CONFIG_ZSWAP > + ZSWPOUT_PMD_THP_FOLIO, > +#endif > THP_SWPOUT_FALLBACK, > #endif > #ifdef CONFIG_MEMORY_BALLOON > @@ -143,6 +146,18 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOU= T, > ZSWPIN, > ZSWPOUT, > ZSWPWB, > + ZSWPOUT_4KB_FOLIO, > +#ifdef CONFIG_THP_SWAP > + mTHP_ZSWPOUT_8kB, > + mTHP_ZSWPOUT_16kB, > + mTHP_ZSWPOUT_32kB, > + mTHP_ZSWPOUT_64kB, > + mTHP_ZSWPOUT_128kB, > + mTHP_ZSWPOUT_256kB, > + mTHP_ZSWPOUT_512kB, > + mTHP_ZSWPOUT_1024kB, > + mTHP_ZSWPOUT_2048kB, > +#endif This implementation hardcodes assumptions about the page size being 4KB, but page sizes can vary, and so can the THP orders? > #endif > #ifdef CONFIG_X86 > DIRECT_MAP_LEVEL2_SPLIT, > diff --git a/mm/vmstat.c b/mm/vmstat.c > index 8507c497218b..0e66c8b0c486 100644 > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -1375,6 +1375,9 @@ const char * const vmstat_text[] =3D { > "thp_zero_page_alloc", > "thp_zero_page_alloc_failed", > "thp_swpout", > +#ifdef CONFIG_ZSWAP > + "zswpout_pmd_thp_folio", > +#endif > "thp_swpout_fallback", > #endif > #ifdef CONFIG_MEMORY_BALLOON > @@ -1405,6 +1408,18 @@ const char * const vmstat_text[] =3D { > "zswpin", > "zswpout", > "zswpwb", > + "zswpout_4kb_folio", > +#ifdef CONFIG_THP_SWAP > + "mthp_zswpout_8kb", > + "mthp_zswpout_16kb", > + "mthp_zswpout_32kb", > + "mthp_zswpout_64kb", > + "mthp_zswpout_128kb", > + "mthp_zswpout_256kb", > + "mthp_zswpout_512kb", > + "mthp_zswpout_1024kb", > + "mthp_zswpout_2048kb", > +#endif The issue here is that the number of THP orders can vary across different platforms. > #endif > #ifdef CONFIG_X86 > "direct_map_level2_splits", > -- > 2.27.0 > Thanks Barry