From nobody Mon Feb 9 00:30:42 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB5DE6E619 for ; Sat, 17 Aug 2024 05:09:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871371; cv=none; b=iyn5mr9wVc2zBMNiXyqT1q2g0aSkXZ0HJmhCRJj/4H/Gf0gv3AiwB5/blyVLUqZAeJK1eiWsUh3wjryk+Lyujt64Bo8VrYrs7aevtMa8OYaIL3Tc35P9yhOUGLu6UBMrNPMabg8nhgwE3W6kT6bXYeWZzUgniASreaXH04Uh3D8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871371; c=relaxed/simple; bh=8aJTLnzMPmjHtUmt/CSvhY9AKnZREM8rFjycd3MYym0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aNtltd8FJ8L7qztKhzp7sCUm8mtDKW7sssrOnC2i+l2ds7kfYXVw4cvaRl3VPWxPjPyNnwbhEzpXmPlypLtwV8/Lr+c/t9ohZz8FJ4C5NAB4mftkJ7Kymon0mmRznxtU06I7SRP6ntgFOMkIP0YxD+/Bi9j4CV8veCReDe5YmVg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=kkWDkZXa; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="kkWDkZXa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723871369; x=1755407369; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8aJTLnzMPmjHtUmt/CSvhY9AKnZREM8rFjycd3MYym0=; b=kkWDkZXaJR9rEdru248RrG6sydONdnS8MDygDqzBDTIuy6Jr0BPTE0JD ZzIH2lricC4gSOKoynWnuqwkrOoSg0TgvEu/7xRO6pxgpPynSSzlx6bL4 ovPp/MGahq9ojszEpKvJ95H3wS3gwA6VHp1J5tPZHN5XjN1W2eR43+OvY eb3xVyrYSgCBD4ZJSkEqVzNaX81Pyajm2m6j6kl6ivtO2BXsfuQ7nrHrY SZMrw+yiSleTT/1fx3CXu+yLo3xMoDDb8yWIOZoPzdbrDjD9Mlai7Ga3T XHkVNmu7rQyb/SiPNZ/ooxRmeVobMXaiEKzjlwuAxOjnZSAC/Ve3j3QiL w==; X-CSE-ConnectionGUID: 0jKjyGBTQA2e/pVDLn8Q8w== X-CSE-MsgGUID: IFwNiohNRyeHsXL+IYGIrw== X-IronPort-AV: E=McAfee;i="6700,10204,11166"; a="25929463" X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="25929463" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 22:09:21 -0700 X-CSE-ConnectionGUID: SVdXdoIIRwOh7Pc03Kd8zg== X-CSE-MsgGUID: Uu+OYl+RRTiJZwt1cW3OLg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="60141492" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa006.jf.intel.com with ESMTP; 16 Aug 2024 22:09:21 -0700 From: Kanchana P Sridhar To: 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, 21cnbao@gmail.com, akpm@linux-foundation.org Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v3 1/4] mm: zswap: zswap_is_folio_same_filled() takes an index in the folio. Date: Fri, 16 Aug 2024 22:09:18 -0700 Message-Id: <20240817050921.18462-2-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> References: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This change is being made so that zswap_store can process mTHP folios. Modified zswap_is_folio_same_filled() to work for any-order folios, by accepting an additional "index" parameter to arrive at the page within the folio to run the same-filled page check. Signed-off-by: Kanchana P Sridhar --- mm/zswap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index adeaf9c97fde..6c5c656ec282 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1358,14 +1358,14 @@ static void shrink_worker(struct work_struct *w) /********************************* * same-filled functions **********************************/ -static bool zswap_is_folio_same_filled(struct folio *folio, unsigned long = *value) +static bool zswap_is_folio_same_filled(struct folio *folio, long index, un= signed long *value) { unsigned long *data; unsigned long val; unsigned int pos, last_pos =3D PAGE_SIZE / sizeof(*data) - 1; bool ret =3D false; =20 - data =3D kmap_local_folio(folio, 0); + data =3D kmap_local_folio(folio, index * PAGE_SIZE); val =3D data[0]; =20 if (val !=3D data[last_pos]) @@ -1435,7 +1435,7 @@ bool zswap_store(struct folio *folio) goto reject; } =20 - if (zswap_is_folio_same_filled(folio, &value)) { + if (zswap_is_folio_same_filled(folio, 0, &value)) { entry->length =3D 0; entry->value =3D value; atomic_inc(&zswap_same_filled_pages); --=20 2.27.0 From nobody Mon Feb 9 00:30:42 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C64880BFC for ; Sat, 17 Aug 2024 05:09:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871372; cv=none; b=NUnd/COaDUAE246Y2B7r7HyUFvggFkoVFr+AX7+4v2ocGgmPHy7l4jxFQpBis7UrI0LU4UUMzJ36WTcAaePoHKb1EgHcOJuPJMbs0qku5wIy8bn5KYfJp9F2Jx7jTsFz23AOp2C4NlX5yE6LkNqs53TxvqH7xLefbkl1EcjCp/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871372; c=relaxed/simple; bh=Hs5osIBnEQbfhkvnt0UdOWrL7Zx29/pIwKoBT11shSE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=js6xgfLW0MgtcaWN8EYfj4r9RV9XGfEHSYzScFWlgCedicdFBakbUL/uf2nwXvVpipLbuSQ8aDyGqVkqAE/CYLC0vUIFwfmq3IiTJCUPjOxTa7oYtnWfGp/qGbZCScD6FgtT7RKmM71sq6sYDGTvxlURuA2Y0S2llsZg3GEQx1A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Ds/jPYC5; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Ds/jPYC5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723871370; x=1755407370; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Hs5osIBnEQbfhkvnt0UdOWrL7Zx29/pIwKoBT11shSE=; b=Ds/jPYC5IlLIJRdKX6gMwxhX0U5KuVXgwBYwPUMuP0i769oId4sOl3Fb LsiX71JWV/IbIbV/FGD7P+sMGA1qvzVJoa7NNB+JCJZ1F9Qwhi6qhezL5 CPMn+PE771752UOihOuYTMyAq07V7ZG9gDpTW0l9cpBCXAVnm8gRjKrLV vX6e+FtmnUiqzAt3T+x6PvI5CSfko0sFo2NrDwQkZMxJFFS4nIo6Awj/k HeM6IZ6kUXriud8SB/MnrGzbhBRqCQW+ZQ2rZyp4F7SZ0JLkClIKtljtZ RGk5m4slKHeGj/jDrqNaYKaIz9ZIJSCql7LPAsYD9POVfJrpM/J2NV46l Q==; X-CSE-ConnectionGUID: nxAipbHkQmS4S0AGG0sm0Q== X-CSE-MsgGUID: zdAzslCOSHuYQHsB8wBjnQ== X-IronPort-AV: E=McAfee;i="6700,10204,11166"; a="25929471" X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="25929471" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 22:09:21 -0700 X-CSE-ConnectionGUID: 45aK0Pq1RiiWmgfsLRGP+A== X-CSE-MsgGUID: BXaEkahsTVqlUNwVVqM3Ow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="60141495" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa006.jf.intel.com with ESMTP; 16 Aug 2024 22:09:21 -0700 From: Kanchana P Sridhar To: 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, 21cnbao@gmail.com, akpm@linux-foundation.org Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v3 2/4] mm: zswap: zswap_store() extended to handle mTHP folios. Date: Fri, 16 Aug 2024 22:09:19 -0700 Message-Id: <20240817050921.18462-3-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> References: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" zswap_store() will now process and store mTHP and PMD-size THP folios. 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.robert= s@arm.com/T/#u 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). 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/zswap.c | 234 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 172 insertions(+), 62 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index 6c5c656ec282..7a712be2f3cb 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -884,7 +884,7 @@ static int zswap_cpu_comp_dead(unsigned int cpu, struct= hlist_node *node) return 0; } =20 -static bool zswap_compress(struct folio *folio, struct zswap_entry *entry) +static bool zswap_compress(struct page *page, struct zswap_entry *entry) { struct crypto_acomp_ctx *acomp_ctx; struct scatterlist input, output; @@ -902,7 +902,7 @@ static bool zswap_compress(struct folio *folio, struct = zswap_entry *entry) =20 dst =3D acomp_ctx->buffer; sg_init_table(&input, 1); - sg_set_folio(&input, folio, PAGE_SIZE, 0); + sg_set_page(&input, page, PAGE_SIZE, 0); =20 /* * We need PAGE_SIZE * 2 here since there maybe over-compression case, @@ -1394,36 +1394,83 @@ static void zswap_fill_folio(struct folio *folio, u= nsigned long value) /********************************* * main API **********************************/ -bool zswap_store(struct folio *folio) + +/* + * Returns true if the entry was successfully + * stored in the xarray, and false otherwise. + */ +static bool zswap_store_entry(struct xarray *tree, + struct zswap_entry *entry) { - 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, *old; - struct obj_cgroup *objcg =3D NULL; - struct mem_cgroup *memcg =3D NULL; - unsigned long value; + struct zswap_entry *old; + pgoff_t offset =3D swp_offset(entry->swpentry); =20 - VM_WARN_ON_ONCE(!folio_test_locked(folio)); - VM_WARN_ON_ONCE(!folio_test_swapcache(folio)); + old =3D xa_store(tree, offset, entry, GFP_KERNEL); =20 - /* Large folios aren't supported */ - if (folio_test_large(folio)) + if (xa_is_err(old)) { + int err =3D xa_err(old); + + WARN_ONCE(err !=3D -ENOMEM, "unexpected xarray error: %d\n", err); + zswap_reject_alloc_fail++; return false; + } =20 - if (!zswap_enabled) - goto check_old; + /* + * We may have had an existing entry that became stale when + * the folio was redirtied and now the new version is being + * swapped out. Get rid of the old. + */ + if (old) + zswap_entry_free(old); =20 - /* Check cgroup limits */ - objcg =3D get_obj_cgroup_from_folio(folio); - if (objcg && !obj_cgroup_may_zswap(objcg)) { - memcg =3D get_mem_cgroup_from_objcg(objcg); - if (shrink_memcg(memcg)) { - mem_cgroup_put(memcg); - goto reject; - } - mem_cgroup_put(memcg); + return true; +} + +/* + * If the zswap store fails or zswap is disabled, we must invalidate the + * possibly stale entries which were previously stored at the offsets + * corresponding to each page of the folio. Otherwise, writeback could + * overwrite the new data in the swapfile. + * + * This is called after the store of the i-th offset in a large folio has + * failed. All zswap entries in the folio must be deleted. This helps make + * sure that a swapped-out mTHP is either entirely stored in zswap, or + * entirely not stored in zswap. + * + * This is also called if zswap_store() is invoked, but zswap is not enabl= ed. + * All offsets for the folio are deleted from zswap in this case. + */ +static void zswap_delete_stored_offsets(struct xarray *tree, + pgoff_t offset, + long nr_pages) +{ + struct zswap_entry *entry; + long i; + + for (i =3D 0; i < nr_pages; ++i) { + entry =3D xa_erase(tree, offset + i); + if (entry) + zswap_entry_free(entry); } +} + +/* + * Stores the page at specified "index" in a folio. + */ +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); + pgoff_t offset =3D swp_offset(swp) + index; + struct page *page =3D folio_page(folio, index); + struct xarray *tree =3D swap_zswap_tree(swp); + struct zswap_entry *entry; + unsigned long value; + + if (objcg) + obj_cgroup_get(objcg); =20 if (zswap_check_limits()) goto reject; @@ -1435,7 +1482,7 @@ bool zswap_store(struct folio *folio) goto reject; } =20 - if (zswap_is_folio_same_filled(folio, 0, &value)) { + if (zswap_is_folio_same_filled(folio, index, &value)) { entry->length =3D 0; entry->value =3D value; atomic_inc(&zswap_same_filled_pages); @@ -1443,42 +1490,20 @@ bool zswap_store(struct folio *folio) } =20 /* if entry is successfully added, it keeps the reference */ - entry->pool =3D zswap_pool_current_get(); - if (!entry->pool) + if (!zswap_pool_get(pool)) goto freepage; =20 - if (objcg) { - memcg =3D get_mem_cgroup_from_objcg(objcg); - if (memcg_list_lru_alloc(memcg, &zswap_list_lru, GFP_KERNEL)) { - mem_cgroup_put(memcg); - goto put_pool; - } - mem_cgroup_put(memcg); - } + entry->pool =3D pool; =20 - if (!zswap_compress(folio, entry)) + if (!zswap_compress(page, entry)) goto put_pool; =20 store_entry: - entry->swpentry =3D swp; + entry->swpentry =3D swp_entry(type, offset); entry->objcg =3D objcg; =20 - old =3D xa_store(tree, offset, entry, GFP_KERNEL); - if (xa_is_err(old)) { - int err =3D xa_err(old); - - WARN_ONCE(err !=3D -ENOMEM, "unexpected xarray error: %d\n", err); - zswap_reject_alloc_fail++; + if (!zswap_store_entry(tree, entry)) goto store_failed; - } - - /* - * We may have had an existing entry that became stale when - * the folio was redirtied and now the new version is being - * swapped out. Get rid of the old. - */ - if (old) - zswap_entry_free(old); =20 if (objcg) { obj_cgroup_charge_zswap(objcg, entry->length); @@ -1512,7 +1537,7 @@ bool zswap_store(struct folio *folio) else { zpool_free(entry->pool->zpool, entry->handle); put_pool: - zswap_pool_put(entry->pool); + zswap_pool_put(pool); } freepage: zswap_entry_cache_free(entry); @@ -1520,16 +1545,101 @@ bool zswap_store(struct folio *folio) obj_cgroup_put(objcg); if (zswap_pool_reached_full) queue_work(shrink_wq, &zswap_shrink_work); -check_old: + + return false; +} + +/* + * Modified to store mTHP folios. Each page in the mTHP will be compressed + * 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 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)); + + if (!zswap_enabled) + goto reject; + /* - * If the zswap store fails or zswap is disabled, we must invalidate the - * possibly stale entry which was previously stored at this offset. - * Otherwise, writeback could overwrite the new data in the swapfile. + * Check cgroup limits: + * + * The cgroup zswap limit check is done once at the beginning of an + * mTHP store, and not within zswap_store_page() for each page + * in the mTHP. We do however check the zswap pool limits at the + * start of zswap_store_page(). What this means is, the cgroup + * could go over the limits by at most (HPAGE_PMD_NR - 1) pages. + * However, the per-store-page zswap pool limits check should + * hopefully trigger the cgroup aware and zswap LRU aware global + * reclaim implemented in the shrinker. If this assumption holds, + * the cgroup exceeding the zswap limits could potentially be + * resolved before the next zswap_store, and if it is not, the next + * zswap_store would fail the cgroup zswap limit check at the start. */ - entry =3D xa_erase(tree, offset); - if (entry) - zswap_entry_free(entry); - return false; + objcg =3D get_obj_cgroup_from_folio(folio); + if (objcg && !obj_cgroup_may_zswap(objcg)) { + memcg =3D get_mem_cgroup_from_objcg(objcg); + if (shrink_memcg(memcg)) { + mem_cgroup_put(memcg); + goto put_objcg; + } + mem_cgroup_put(memcg); + } + + if (zswap_check_limits()) + goto put_objcg; + + pool =3D zswap_pool_current_get(); + if (!pool) + goto put_objcg; + + if (objcg) { + memcg =3D get_mem_cgroup_from_objcg(objcg); + if (memcg_list_lru_alloc(memcg, &zswap_list_lru, GFP_KERNEL)) { + mem_cgroup_put(memcg); + goto put_pool; + } + mem_cgroup_put(memcg); + } + + /* + * Store each page of the folio as a separate entry. If we fail to store + * a page, unwind by removing all the previous pages we stored. + */ + for (index =3D 0; index < nr_pages; ++index) { + if (!zswap_store_page(folio, index, objcg, pool)) + goto put_pool; + } + + ret =3D true; + +put_pool: + zswap_pool_put(pool); +put_objcg: + obj_cgroup_put(objcg); + if (zswap_pool_reached_full) + queue_work(shrink_wq, &zswap_shrink_work); +reject: + /* + * If the zswap store fails or zswap is disabled, we must invalidate + * the possibly stale entries which were previously stored at the + * offsets corresponding to each page of the folio. Otherwise, + * writeback could overwrite the new data in the swapfile. + */ + if (!ret) + zswap_delete_stored_offsets(tree, offset, nr_pages); + + return ret; } =20 bool zswap_load(struct folio *folio) --=20 2.27.0 From nobody Mon Feb 9 00:30:42 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D77F684A31 for ; Sat, 17 Aug 2024 05:09:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871373; cv=none; b=QWGpua7t8ujSg3LzcMn9n86Ijns1H3ccvAPrAqyMdCPrBsoI+iYHkWlL03Alk6kjwz44mK8LiggFdGHfzghIDMEc3hlqjFHS1txoqVBr4vq0gEW5f2TJF5gmNZaUYDy3W1EXzpzT/LFlI1Vj0MFONm5UbDpxOkDSjr7FqaPjKuM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871373; c=relaxed/simple; bh=Rhd+o6cIvQZsonqH5BjtpwXRBNEn4sYl6ZxLr6ObqFU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=BO01vjGjpSgppYlXBoGP46I/I7OXjfS682TP3ESPjwCl2TePak9mikLPc2P9uBUabsMhuP0IitO0dbGkk62B8NjYtH+cHtTvLQfs3eEt/2TmQbRsXZxdMB/15ss7AlPHtpMcfMKqBlwkVfq9onVPBhpI4kwa5mSgTAHSD9v5mr0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZsNhL8zk; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZsNhL8zk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723871372; x=1755407372; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Rhd+o6cIvQZsonqH5BjtpwXRBNEn4sYl6ZxLr6ObqFU=; b=ZsNhL8zkBlfN76rfgr0HQUP+SEPtbQ0tx7oIcjxSuKLAS2GPl0zikari o+dLOFYpAEq9uiu4o7A5DA7x7UELr5uSOWNH3rLCDNCGPdAMkYQIuT0nO VnIg3D0/21wrnSSjF+H93pONS61mpRPhDFplCYMRAbCadJzpf8Xw9w85d ftc6+OLehPPqQZdQP/y6i5pDVwn3Z5NorQvGFKlldnfsPzAzq0hLDtpMN q5risecZ0ICw0vxa3LSk8Z7+ee9MKMl4I1wafKqfGCfVKY4qVSV1tfieG mbYfLrdhXo0UFnw2jzCWn6TMYqj7MksDoKlhGe/bFRLHzb0GwpARhfIsX Q==; X-CSE-ConnectionGUID: aNx2WiFaSKqnJxuzwFWf4g== X-CSE-MsgGUID: U3MjBQ7ZRzid4lMdlDmN1w== X-IronPort-AV: E=McAfee;i="6700,10204,11166"; a="25929478" X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="25929478" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 22:09:21 -0700 X-CSE-ConnectionGUID: ZSoOEOTiSpKi7SFuA8U4wg== X-CSE-MsgGUID: xlveTXNuQU62fSdNy5hU2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="60141498" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa006.jf.intel.com with ESMTP; 16 Aug 2024 22:09:21 -0700 From: Kanchana P Sridhar To: 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, 21cnbao@gmail.com, akpm@linux-foundation.org Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v3 3/4] mm: Add MTHP_STAT_ZSWPOUT to sysfs per-order mthp stats. Date: Fri, 16 Aug 2024 22:09:20 -0700 Message-Id: <20240817050921.18462-4-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> References: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a new MTHP_STAT_ZSWPOUT entry to the sysfs mTHP stats so that per-order mTHP folio ZSWAP stores can be accounted. Signed-off-by: Kanchana P Sridhar --- include/linux/huge_mm.h | 1 + mm/huge_memory.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index e25d9ebfdf89..44609d84f2dd 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -273,6 +273,7 @@ enum mthp_stat_item { MTHP_STAT_ANON_FAULT_ALLOC, MTHP_STAT_ANON_FAULT_FALLBACK, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE, + MTHP_STAT_ZSWPOUT, MTHP_STAT_SWPOUT, MTHP_STAT_SWPOUT_FALLBACK, MTHP_STAT_SHMEM_ALLOC, diff --git a/mm/huge_memory.c b/mm/huge_memory.c index f4be468e06a4..7e97b6ed6ff1 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -574,6 +574,7 @@ static struct kobj_attribute _name##_attr =3D __ATTR_RO= (_name) DEFINE_MTHP_STAT_ATTR(anon_fault_alloc, MTHP_STAT_ANON_FAULT_ALLOC); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTHP_STAT_ANON_FAULT_FALLBACK); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FAULT_FAL= LBACK_CHARGE); +DEFINE_MTHP_STAT_ATTR(zswpout, MTHP_STAT_ZSWPOUT); DEFINE_MTHP_STAT_ATTR(swpout, MTHP_STAT_SWPOUT); DEFINE_MTHP_STAT_ATTR(swpout_fallback, MTHP_STAT_SWPOUT_FALLBACK); DEFINE_MTHP_STAT_ATTR(shmem_alloc, MTHP_STAT_SHMEM_ALLOC); @@ -587,6 +588,7 @@ static struct attribute *stats_attrs[] =3D { &anon_fault_alloc_attr.attr, &anon_fault_fallback_attr.attr, &anon_fault_fallback_charge_attr.attr, + &zswpout_attr.attr, &swpout_attr.attr, &swpout_fallback_attr.attr, &shmem_alloc_attr.attr, --=20 2.27.0 From nobody Mon Feb 9 00:30:42 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A69885283 for ; Sat, 17 Aug 2024 05:09:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871374; cv=none; b=ZF1Nu21DY6XNLPkIFZutTADH8IELyF2Hl/g5pm/3e3M4PplkMlX9WN8qDP9QXuR2Ulmac+KAj9AwuQDBYY/bmSMniMPK4BATR/SDNjd8j0C7XWzWwyMEzZKQ0jgFS38gh20zHrPhuTS78AbRw2HxINr0XrNHDqrvhqDdfVRipkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723871374; c=relaxed/simple; bh=pIv8/Aymq35M3mk+Ip2dqi+IlPE8wYobMr4oum9ku1Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=YTnpN7TFJIuJS6M5Mg7dtuTpZvfoYzwfTRHZFzSSSrVYODj7o5Bvg4YjqlbGJYEqeZjJlPVnu0VcUuG77k2mr9F/Dy7Ppjw+b+zwMa9TOjm3uOMGdD344U6vAJbkF7X49nDEJxr3am20Vnh3fb7O8YIu5s1zx1x3JRmMKsCF4/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ioVR7Rqr; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ioVR7Rqr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723871372; x=1755407372; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pIv8/Aymq35M3mk+Ip2dqi+IlPE8wYobMr4oum9ku1Y=; b=ioVR7Rqr9ZgapfLWy4X+8U+OtZ98GG8Q+eOWXgGRZqMyk3GtFWPsFrM+ s9A2xNsYdDO9d7zHmM/UAY8hFYQ37263kzjgECEHhlkSOxaWuxajv/xQv 9UR4dyoVIekgcuXmLMtUf3ldjSH5j8kVemYG0g6+qhNPGsAAkN0AvSxv6 yO/YkkxFxLbX83sumQlqQhODtq25V82Zj8RAz+2NN8octvcxdEbb4n6p0 bdEhV4ENLzcRewcx+7dVOeEBLuyolN6DQ2o60Zao1vdIbXqtuw6e6oT8Z Se2Ypnh5qfTF4dANEsfk3Dn1tpP8KiHtpT8UF1EK2XqWkE502kZ0sZ4vG w==; X-CSE-ConnectionGUID: i683/gphS+S53/42wCH/ag== X-CSE-MsgGUID: jchyHopvQAacm/kbxZwHIw== X-IronPort-AV: E=McAfee;i="6700,10204,11166"; a="25929485" X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="25929485" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 22:09:22 -0700 X-CSE-ConnectionGUID: G3ES7ewjRXi5YjsXLL3eQQ== X-CSE-MsgGUID: fZPmCcW6RFSDaGvIag7BFg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,154,1719903600"; d="scan'208";a="60141501" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa006.jf.intel.com with ESMTP; 16 Aug 2024 22:09:22 -0700 From: Kanchana P Sridhar To: 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, 21cnbao@gmail.com, akpm@linux-foundation.org Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v3 4/4] mm: swap: Count successful mTHP ZSWAP stores in sysfs mTHP stats. Date: Fri, 16 Aug 2024 22:09:21 -0700 Message-Id: <20240817050921.18462-5-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> References: <20240817050921.18462-1-kanchana.p.sridhar@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If zswap_store() successfully stores an mTHP, it will be counted under the per-order sysfs "zswpout" stats: /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/zswpout Other block dev/fs mTHP swap-out events will be counted under the existing sysfs "swpout" stats: /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/swpout Signed-off-by: Kanchana P Sridhar --- mm/page_io.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/page_io.c b/mm/page_io.c index ff8c99ee3af7..debd04fbdfd0 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -172,6 +172,12 @@ int generic_swapfile_activate(struct swap_info_struct = *sis, goto out; } =20 +static inline void count_mthp_zswpout_vm_event(struct folio *folio) +{ + if (IS_ENABLED(CONFIG_THP_SWAP)) + count_mthp_stat(folio_order(folio), MTHP_STAT_ZSWPOUT); +} + /* * We may have stale swap cache pages in memory: notice * them here and get rid of the unnecessary final write. @@ -196,6 +202,7 @@ int swap_writepage(struct page *page, struct writeback_= control *wbc) return ret; } if (zswap_store(folio)) { + count_mthp_zswpout_vm_event(folio); folio_unlock(folio); return 0; } --=20 2.27.0