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 115CBC3DA4A for ; Wed, 14 Aug 2024 23:25:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 975336B0093; Wed, 14 Aug 2024 19:25:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 924E76B0095; Wed, 14 Aug 2024 19:25:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C5B26B0096; Wed, 14 Aug 2024 19:25:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5ECD06B0093 for ; Wed, 14 Aug 2024 19:25:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0CDC51C471A for ; Wed, 14 Aug 2024 23:25:03 +0000 (UTC) X-FDA: 82452433686.27.CFBB694 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 4434340009 for ; Wed, 14 Aug 2024 23:25:01 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MDDFRo17; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723677847; a=rsa-sha256; cv=none; b=5XQdzTu1wvqp+KDbA8rDY2kojLTSCC9kSjONMFzzBsyQ/yJAyy/uLcqSWV7kdI/5kRVuQc Umrm1Gdakx+rASn58arsItKbbLX7ORuTZgVoKajqpiUVrbrOnL+J+VExQ4SeekeaQGnMjQ 4axArAYQeF2lJwMI7LMy7yQRmFjoij8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MDDFRo17; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723677847; 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=Y5ecmjJfcT0FCCG8RwUU6alXyHI9eWN1URTy75OZxMk=; b=DfP/iZfq2hO+jm9gCUDxsA8A+djTy1rDpMFRahWkBXCMVTiiWJqeXdLRH1tE+5N9cd/4oU qZ2uoChLH88z/54okSJUwJ73EpIXWhaRFBd3JdpE8h/lzIfdntlvMkbPzA76N75yPV8sTo chukTpmrnLyyW8NseSNxawtg3PbgaOE= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4f887be28e7so148452e0c.0 for ; Wed, 14 Aug 2024 16:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723677900; x=1724282700; 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=Y5ecmjJfcT0FCCG8RwUU6alXyHI9eWN1URTy75OZxMk=; b=MDDFRo17sZ3ezbYGStiRdR/yxnVmcdC9I19hFTaIxIk59S3bkuA3qQ6+5y8oX72uEa V5bRcJHw0DGOk/3Wn6lGyPzDI1hNW+3ASLjwZjKA1+LW/I6zUMOy3XvY4qXkbg/K65ID WxltiBTR1yQP08UicCmgcwoRDdwaCs/d4Op98ETvDLnMvcBUkE8HLI3GF7frVdq1KEu/ UDBB4YNFd+rZlGAKJvGOcV8GF3RQqQ11PdxNOKJLqFyQ4bxEb/V0YIkDpYFkamrcBsNy JfxGLJmhFnBh631WgUWPGKhmkS3Kh/mj+hToPHTdAi1/og53oB35FVp0Y9RSAsTvDLiV qn7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723677900; x=1724282700; 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=Y5ecmjJfcT0FCCG8RwUU6alXyHI9eWN1URTy75OZxMk=; b=MnsyTWgGa+GfWbo8y8GMejDJUFULNgzfmVBNMjEUkrbvcUknVR3Ac3f3/RgvK5KQjd VgonwESL1n1z8aKznCN1m7g/y9LkgemV3JT8uXP4HHU2xnrXzP5nuElDbye2hRCK3y+t 7YCTn95j+FFNm4M3aksIc4vKcsorvnSjkhcmb9YAi7F0fkE6ag1MzD+oO8w2JnA4lbmi prZ4OPjRZ3L575MgOAqc2c6aXr5aLUjub/090Djjl3gp6JOQKeYKg0CeWw9ADEKPbYzD sE7q7ZO2keCghH3pNk0Ex6IZOTTzFo0DOMWTBXK7RVsz2ABjLAAylZ40ab6x7/Y6qzmf 3CsA== X-Forwarded-Encrypted: i=1; AJvYcCVmtkZSu2NOQ2oKsB1r92vn++DY5bxUzFSaBV9AjuqPIaGDwAoC9nUr7lbnk9KiufamyL1cYNh7mxG8Nl8wb0jLo0k= X-Gm-Message-State: AOJu0YyOJtCl8OlcGGW92jFtINBP68z8g145C4kAoTc0IKargyyDTZCK IQJqzwSCL5i/iL8cOqzV7XgEYP62b56FDbndRA0e9gy0WDABkELEXh1kMcv4tNJn2gUTa8GBr2x UtxPj7IjA0hWMnw2OIieyv7iD02A= X-Google-Smtp-Source: AGHT+IE+yqsMTXX2EMGjcI5YDI2FitTMU+9sTKfPOY8NtOV2hE7cHar2lJU2iNvDQpw72fDS70BofFf5VQ9IgpWqxH0= X-Received: by 2002:a05:6122:2524:b0:4f5:199b:2a61 with SMTP id 71dfb90a1353d-4fad23165a6mr5381411e0c.9.1723677900129; Wed, 14 Aug 2024 16:25:00 -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: From: Barry Song <21cnbao@gmail.com> Date: Thu, 15 Aug 2024 11:24:49 +1200 Message-ID: Subject: Re: [RFC PATCH v1 2/4] mm: vmstat: Per mTHP-size zswap_store vmstat event counters. To: "Sridhar, Kanchana P" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "yosryahmed@google.com" , "nphamcs@gmail.com" , "ryan.roberts@arm.com" , "Huang, Ying" , "akpm@linux-foundation.org" , "Zou, Nanhai" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4434340009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: rk9o3i7um9brnr1oedx6aaj691tsfbtr X-HE-Tag: 1723677901-216731 X-HE-Meta: U2FsdGVkX1/yCBn7VjuhyaASg/xCFerMWTp0L19MJOE/g1xc8TEnwmWrPxxDoj1ujdVqqiucypc7n27PmpORfI0gfnSQks1BJ6hxckVjj2cP+0cs3xsmNIWTGrFs+sPzGGXtYZ+BgxM29x9c96wZlvTazFh+NE0UJJa7YAfs39PGvf54HRGm727dXtMI69/A3Yk7f6dVKzcSmBqCEMRKzZBrSq/ptHnX5Ly0vJ+PnEH0pGdHz8UbcuK8PrsbgYHCYUe+PcXQQDtBsOW5TThPcvfllR+/Xu+FEkI2bryKtLt6Oux2Plqo2cSUlaiTwahxuU8fBzJDwK1mriqZ1KMSWlCRmDJOwweXsmb6w0yJH+NANVUYZrLZAcNYOhYqM8Sz+5OiPnKOLpFercyj/wFrf3P/Fx2DZZ7UR/sOuoxQ+zKV7+FQCB1muNXig7CNIVKG1G0SJccVJM6LWOZysE+Ds+yfXrUQPQVgG89JUm6VaszYo0NjGZAfbH0RT5WTVvaMzrhr8DFqWhLBh7pRskkrLFu5pl9eKag546Gnv6aOuQknqhXeJQyBO+OnqEgk2ahTQegMOBMhA8UI3qqERJUPO3YSaV5uOxZlKVnRX93AxWs1uxntdCFK8ppZG9lyPx0iiuIj+ErihpbX7h2KCulrc8ieksFVnM4sldtONzEhTKDZlcYjl1Va8iInjnxDc5OoIR3Yp5pth6+q5Gjq6JSWBjhclQBYgNwmzbSllH7Y+fY/C2G1iXT89m7GV/U77T25ihgXE/tl6yjhSHHIKzBenfoopfP2DLKK7fIffkoXsn6/DzHqPqOQ0/W5XDvuXl1iLF+W4Q4FNbtEeIDIGeusrDP2ccSGHXZ6zuKbrFI0hYvIHegL5m1TYJZVN2iW5Nrq88spvoSvtxRA7P3FTuzBbBVO9fQi11HiHB5XMF0TY2Q/HA7DMb4y4LBBNtnZc5pp+AofZAlk83oevyc6Q7N Yja9vQGl yB2oEcEM61hEHu7Wfn5+NQlv0KTTRwGFLjU30jocsui8YsjZuyiDH1qGiG/3zBpsWcOZ1BtCktrdvG/11s9iQOIr4v61oFMR8E0OvsguAjl6/HB1EopfUMQekQXM7zXNGlJhIPRpZOZxz18vdOWsb691/5KjX2BAvzGfN4MrsPvQHOtMiTcCB11deKdpGGVhBE6J76A30FwDWTkvpiyeVd/LGcGWLOLlPRmKxXLpDicYYZ8VCAwB9IZrvMAvTDaydbbwHbP3b1PkwLrdrm+VnV+kSv/nwzMfhDHwawl8T90o92aNRnLyV6grgubxJYfj0NLFcnYEZ99oznciYU7Y5+Tq6VFdo0fKVkslbwdvBOIKxWyLjLDhvhBqwjt+jJpiFW3GiebkawNo6nGpzGISrfprcpYEPP3FQYn2ch9Wqh12rXHS0PZvZhVZSQhMbn33NUaa3pmxMxB1vMnztW7dZLJa/0clTFmaaT+JJzNLtoaC7PYfI/FrK6kse1qbeBLOFPZfT/lnTxQ2tCecsYiE0KyTRt/Gt/JtVetsJfsftXj96C0k0vYGdM+xvNCdswMRR5z+raRao3dgPZXkDSrzzChw22t5mTnwfx1B99sqQ0XzF2NSGIiQcbAx+//yN89mQjk+djtLwdzHjblqwMhyuy38CzMZX72Z3v9UlwcdNyFkS3Do+cDnQdIHJLHX3JoR7ZE+n8pTR2leoS9PpLx/zkeUFPJ+PO3Y2OELjtDu0YAcZ+JYc/grbsAIhcg== 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: List-Subscribe: List-Unsubscribe: On Thu, Aug 15, 2024 at 5:40=E2=80=AFAM Sridhar, Kanchana P wrote: > > Hi Barry, > > > -----Original Message----- > > From: Barry Song <21cnbao@gmail.com> > > Sent: Wednesday, August 14, 2024 12:49 AM > > To: Sridhar, Kanchana P > > Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org; > > hannes@cmpxchg.org; yosryahmed@google.com; nphamcs@gmail.com; > > ryan.roberts@arm.com; Huang, Ying ; akpm@linux- > > foundation.org; Zou, Nanhai ; Feghali, Wajdi K > > ; Gopal, Vinodh > > Subject: Re: [RFC PATCH v1 2/4] mm: vmstat: Per mTHP-size zswap_store > > vmstat event counters. > > > > 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 instea= d > > > 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? > > Thanks for the code review comments. This is a good point. I was keeping = in > mind the convention used by existing vmstat event counters that distingui= sh > zswpout/zswpin from pswpout/pswpin events. > > If we want to keep the distinction in mTHP swapouts, would adding a > separate MTHP_STAT_ZSWPOUT to "enum mthp_stat_item" be Ok? > I'm not entirely sure how important the zswpout counter is. To me, it doesn= 't seem as critical as swpout and swpout_fallback, which are more useful for system profiling. zswapout feels more like an internal detail related to how the swap-out process is handled? If this is the case, we might not need this per-size counter. Otherwise, I believe sysfs is a better place to avoid all the chaos in vmst= at to handle various orders and sizes. So the question is, per-size zswpout counter is really important or just for debugging purposes? > In any case, it looks like all that would be needed is a call to > count_mthp_stat(folio_order(folio), MTHP_STAT_[Z]SWPOUT) in the > general case. > > I will make this change in v2, depending on whether or not the > separation of zswpout vs. non-zswap swpout is recommended for > mTHP. > > > > > > > > > > > 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, PSWPOUT, > > > 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? > > Agreed, will address in v2. > > > > > > #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. > > Agreed, will address in v2. > > Thanks, > Kanchana > > > > > > #endif > > > #ifdef CONFIG_X86 > > > "direct_map_level2_splits", > > > -- > > > 2.27.0 > > > Thanks Barry