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 7C394CF9C69 for ; Tue, 24 Sep 2024 17:40:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3AF36B0096; Tue, 24 Sep 2024 13:40:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEA756B0098; Tue, 24 Sep 2024 13:40:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB1C66B00A2; Tue, 24 Sep 2024 13:40:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AD2A96B0096 for ; Tue, 24 Sep 2024 13:40:18 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5CD6FC014E for ; Tue, 24 Sep 2024 17:40:18 +0000 (UTC) X-FDA: 82600345716.25.C44AE2C Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf25.hostedemail.com (Postfix) with ESMTP id 91BFEA0011 for ; Tue, 24 Sep 2024 17:40:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HosSzN4s; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727199528; a=rsa-sha256; cv=none; b=NndHsG7VaGYxPTHYtpXWGsTtpHs9RuVUxLfp5E6TEylNnaLTmayhsXQQEfCGWz9qkYv9pa U0fh2U1+e14biJi7Ot6vIYUhkCnIziekkCMWtkSZRPP5ZD5GtsgMmPOHhZhrh50asgBPzE tsjiRCBIRoYqBW+HT5Bc7RrALAhQT/c= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HosSzN4s; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727199528; 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=eiwagejtmdEAMVRH9GY/YhmfCZ26zHU5MaB8DwQPKCU=; b=YWjeSjxPUytAvgJcnnPcVl+7DBuUxa7E5+lZLlOiTvsC6D6k9Nr1PaRvYMq6kDWsRgEvkL BMM8q6L1bPZJjnrKlpbN3YaNvaJjIRKel+cW9XXcQRXi+KBXM9HXsPZj+XQEKpp52+xb6/ OxlGcxcBOunU7bOodduh3V6VvRRppTg= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6e129c01b3bso21738277b3.0 for ; Tue, 24 Sep 2024 10:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727199615; x=1727804415; 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=eiwagejtmdEAMVRH9GY/YhmfCZ26zHU5MaB8DwQPKCU=; b=HosSzN4sTYsPW+Y3w4e6Z8AtXjgcBuPG4xAl97sWd1y9qqlq3lmAYfhwtDVe8ZsQIX /7N7fw7V43noQ3Jj6ymEcfodMuXVXm5KbuJVCvW2QzHt5dNFnUP4p4dNNJlWbuP+RmOe hjwIRGkIs3+Ty5Un9r4Xk4X0+5CQuLyyd/xglYANrVWeiFCJg9/Ckv8tOtfPkxkMi6IC egkJqxEULzM1m0dcjR+vBL4+o/KT1izBlp1XHPVNNECd6Ig6v8EUXlinSzSTiZRyUmKL lhgVmnkfPWsYL5OL0XErTITrljcRW4KJPFNQ+GyudprZQBy885CoQEcP2CM3jSVKG4F7 rYGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727199615; x=1727804415; 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=eiwagejtmdEAMVRH9GY/YhmfCZ26zHU5MaB8DwQPKCU=; b=NOp8i0SOKAIU7lDFE8cUdVvnETdkRePZh+gh38hW/EurhWA5AqPMcGNvcg5D/7v6nv 0LCQFJxJx7Kd2CCjrgAIjmLo4w3Vxl8v+/2kORHBHI8uFFwpi7rFtgZoqSSSSG8FSP64 gePxgq22K4MmcOgKKFZL3xzLxWwvx7gYlYrasFOYJZOzSWODrTfC4NOG+ZlYpEGA2YK5 +1o4HoIe6EWr+xZ0YnUDpdeN2t+61S1bANHrbQ/RnS2E7S210SWJWKtP3avaEPxovb1g 3W+jasyOfK4nlqd0SEqLfqeVmN6TWBtiQyyRjEPmKqgHs52WbHnzA+TDZT7DsQpcWFXL h60A== X-Forwarded-Encrypted: i=1; AJvYcCUqa6uYlpMipHxOiiYIdVOBOb/5OZITFwJSX/13vqYfFgOJt7QV4lKcu4qgWF1dGlVb4YITZGYNvA==@kvack.org X-Gm-Message-State: AOJu0Yw+EFcujgI19QeT1QRk2FwTvTdSGmPhdcZsabiVAEZFOGtpz/Js qJEbps9HdtFf6a7yo1mw3pA7B9pbWyH0Ip3wwMAQweuYoTGiDBY5o1K1b8YCj3hwrTEjEIemfOC hYp5bQROZS/KHdaSVYL1JjaWci91kgRb2GeI= X-Google-Smtp-Source: AGHT+IGrOSjhuFGPtW+mgJeBjySxDJdCGOugVpXpKH+y02RPYVZ399f8ct2HR5IKi5aQwBWEoR/dXQTid4231a4cUB4= X-Received: by 2002:a05:6214:460f:b0:6c7:cc6b:f0f5 with SMTP id 6a1803df08f44-6c7cc6bf13emr207925086d6.13.1727199224820; Tue, 24 Sep 2024 10:33:44 -0700 (PDT) MIME-Version: 1.0 References: <20240924011709.7037-1-kanchana.p.sridhar@intel.com> <20240924011709.7037-7-kanchana.p.sridhar@intel.com> In-Reply-To: <20240924011709.7037-7-kanchana.p.sridhar@intel.com> From: Nhat Pham Date: Tue, 24 Sep 2024 10:33:34 -0700 Message-ID: Subject: Re: [PATCH v7 6/8] mm: zswap: Support mTHP swapout in zswap_store(). To: Kanchana P Sridhar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, yosryahmed@google.com, chengming.zhou@linux.dev, usamaarif642@gmail.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, 21cnbao@gmail.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-Rspamd-Queue-Id: 91BFEA0011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: n8ncdkpsg9496wynezibjnxqh7disyih X-HE-Tag: 1727199616-42241 X-HE-Meta: U2FsdGVkX19LCmxdqlQF5BcuxiXZA1I0Sd/anZrRnXZwGJUEtVFt0oCltDEzkobz9KQtc2wpwf5Pz697z9V2pbqmngPl+cLIaQEyxFDe5a85+pNYmUurO9LjGd8gLt+SPGxV3uspEatjmsK1v7ymPYeqRygkIqAZGWf3ltSkbIax3YCbi4Z9Turmfq8Xk/s7C/qmLloSshfCPGzCQUQPmeQVGwq67wDwXkOxb4V5bTAM4f0PJzkKDaKjb3x5d8AdFLD+AYlnux1fVhoXoBzpmgMy4h1eJv/h56ijPDovrPjvgeMqs+bI1M/OjyiwXGCn4AqtBpKRntB0lpD7I4RCKwXH4pICKA0aGHpbCaklf6eZhYJNvHXwpK1QumG/qcSq8yRqmA4r8Ht76zbF/chU2sgkP9iVxh20FiNtMiNHam3wpXAmbzzqg3Nwc5UDel5FxMeOQo2c3kFwCVbob3hLS/frjZ2LpWUI+L1BhdCTg+flcyBWlJmmeEwGhtjlPpycXGGkNg301KQkMphHxVpzmuk32K8fS5yVlz0YtjZ9uqhorxyzI0P8xPLeL2knerPpBZ6nzXj8Z+bBTmXpYCc3vDvjmojVEg5U1FDbHa0zBPrFyLsCyUg+S46oOozFwAdtaQFoE/OrS5TgYfmdYRL9+PdO6US7mUF1JvBgS9RpguiD8ObRmZRkDxDhPU1lO8M+YbgHWh4fEOYuPfNCsrZ2aF3TX/b1lNdNVCOQNDAKWQRdHRhUWjs6+2Q9vESr014G5hc3YOVOuhjQKQIgU1hhGlm5FcsEvYi0Mj95AzrA543JzbSFA4bD04QPPK7z+sNKRnqpSDDmFT5xiur0W8AdGJWE15430zTXhvC7cfw29m3rXeg6G75wFj+x/t/Lq3viB3pqaPTMbpB5pMeCHBljC+Ii8poAhMuxj3pB7t6mtm1dPir28iblmyF2xuTEbrhqtQxVIM94GFDoafO7/9s KVVgVNQ9 XmfEreSCoLNzRlakkxKo9/qR03LxL4Vq/J8i2tJEDtCLUbXyeWV7JnSbZAKSHUeLjux1ZVCqHeHvALsXZF/J19lnMk9FFgm+rPdJgn+uQygE8iT+Hh05RKQICR3D2tjJ3HvLMP0IUp1WwQ935zAvjsp8FOF5PV/kvFs2WSefVIDVkFPd8O3P9CVI6wErA42Fjb1X7WKNqxVz5qW157Q80LMisNRiksQybyDNjd6vitwA+UgMVopStizv7LkrzFvuEynAtQAcfia9gc44oHM/x3L92RfgWJBzz5jSzYy8B5y8S+9Dr1IDAu7lrMScbVx4x9aSJjC5yXMOkJABrzGw1+7A9oMn2nRYhAq3yxs3U/QSJiRtPGNlPfBtrm4ESfU3cLZnkovv6xPxet7ur0Zop234ZQMwkPXVQk1N5bs5DvlHDXUy9OT4nfOlc5wSlu5v/Ug5Q4wfnjdMsvW4AOJXts/7IrGn+Y4j1TMW9 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 Mon, Sep 23, 2024 at 6:17=E2=80=AFPM Kanchana P Sridhar wrote: > > zswap_store() will now store mTHP and PMD-size THP folios by compressing > them page by page. > > This patch provides a sequential implementation of storing an mTHP in > zswap_store() by iterating through each page in the folio to compress > and store it in the zswap zpool. > > Towards this goal, zswap_compress() is modified to take a page instead > of a folio as input. > > Each page's swap offset is stored as a separate zswap entry. > > If an error is encountered during the store of any page in the mTHP, > all previous pages/entries stored will be invalidated. Thus, an mTHP > is either entirely stored in ZSWAP, or entirely not stored in ZSWAP. > > This forms the basis for building batching of pages during zswap store > of large folios by compressing batches of up to say, 8 pages in an > mTHP in parallel in hardware, with the Intel In-Memory Analytics > Accelerator (Intel IAA). > > A new config variable CONFIG_ZSWAP_STORE_THP_DEFAULT_ON (off by default) > will enable/disable zswap storing of (m)THP. The corresponding tunable > zswap module parameter is "mthp_enabled". > > This change reuses and adapts the functionality in Ryan Roberts' RFC > patch [1]: > > "[RFC,v1] mm: zswap: Store large folios without splitting" > > [1] https://lore.kernel.org/linux-mm/20231019110543.3284654-1-ryan.robe= rts@arm.com/T/#u > > Also, addressed some of the RFC comments from the discussion in [1]. > > Co-developed-by: Ryan Roberts > Signed-off-by: > Signed-off-by: Kanchana P Sridhar > --- > mm/Kconfig | 8 ++++ > mm/zswap.c | 122 +++++++++++++++++++++++++---------------------------- > 2 files changed, 66 insertions(+), 64 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 09aebca1cae3..c659fb732ec4 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -59,6 +59,14 @@ config ZSWAP_SHRINKER_DEFAULT_ON > reducing the chance that cold pages will reside in the zswap po= ol > and consume memory indefinitely. > > +config ZSWAP_STORE_THP_DEFAULT_ON > + bool "Store mTHP and THP folios in zswap" > + depends on ZSWAP > + default n > + help > + If selected, zswap will process mTHP and THP folios by > + compressing and storing each 4K page in the large folio. > + > choice > prompt "Default compressor" > depends on ZSWAP > diff --git a/mm/zswap.c b/mm/zswap.c > index 8f2e0ab34c84..16ab770546d6 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -127,6 +127,14 @@ static bool zswap_shrinker_enabled =3D IS_ENABLED( > CONFIG_ZSWAP_SHRINKER_DEFAULT_ON); > module_param_named(shrinker_enabled, zswap_shrinker_enabled, bool, 0644)= ; > > +/* > + * Enable/disable zswap processing of mTHP folios. > + * For now, only zswap_store will process mTHP folios. > + */ > +static bool zswap_mthp_enabled =3D IS_ENABLED( > + CONFIG_ZSWAP_STORE_THP_DEFAULT_ON); > +module_param_named(mthp_enabled, zswap_mthp_enabled, bool, 0644); > + Hmm, so this is a runtime knob. Also, should this be zswap_thp_enabled? :) > bool zswap_is_enabled(void) > { > return zswap_enabled; > @@ -1471,9 +1479,9 @@ static void zswap_delete_stored_offsets(struct xarr= ay *tree, > * @objcg: The folio's objcg. > * @pool: The zswap_pool to store the compressed data for the page. > */ > -static bool __maybe_unused zswap_store_page(struct folio *folio, long in= dex, > - struct obj_cgroup *objcg, > - struct zswap_pool *pool) > +static bool zswap_store_page(struct folio *folio, long index, > + struct obj_cgroup *objcg, > + struct zswap_pool *pool) > { > swp_entry_t swp =3D folio->swap; > int type =3D swp_type(swp); > @@ -1551,51 +1559,63 @@ static bool __maybe_unused zswap_store_page(struc= t folio *folio, long index, > return false; > } > > +/* > + * Modified to store mTHP folios. Each page in the mTHP will be compress= ed > + * and stored sequentially. > + */ > bool zswap_store(struct folio *folio) > { > long nr_pages =3D folio_nr_pages(folio); > swp_entry_t swp =3D folio->swap; > pgoff_t offset =3D swp_offset(swp); > struct xarray *tree =3D swap_zswap_tree(swp); > - struct zswap_entry *entry; > struct obj_cgroup *objcg =3D NULL; > struct mem_cgroup *memcg =3D NULL; > + struct zswap_pool *pool; > + bool ret =3D false; > + long index; > > VM_WARN_ON_ONCE(!folio_test_locked(folio)); > VM_WARN_ON_ONCE(!folio_test_swapcache(folio)); > > - /* Large folios aren't supported */ > - if (folio_test_large(folio)) > + /* Storing large folios isn't enabled */ > + if (!zswap_mthp_enabled && folio_test_large(folio)) > return false; Hmm can this go wrong somehow? Can we have a case where we enable zswap_mthp_enabled, have a large folio written to zswap, disable zswap_mthp_enabled, and attempt to store that folio to zswap again. Now, we have a stale copy in zswap that is not invalidated...? Or am I missing something here :)