From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 E26AA2FB6 for ; Sat, 28 Sep 2024 02:16:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489784; cv=none; b=EdOvoi4o9NFec/1yKOgVYiWjq25ui04TXDnLfcEIXHQY4nc/OUDu2gtFoaL2VR1lSLA/R8KN4eRf6P56zmvt8+L7Ty6rFPal7BU0fQM2M/SO3drjv7ri+LxA9Ya15a8ZkPOGa5cDoFpSFNEXF94JHhyuY7k/5/gmUIM+yp+WtDY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489784; c=relaxed/simple; bh=IbCXass7UYncWYJbpbqgopMF9OvpwOCCnOnS4dLfg9g=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=nI0p9w+aKnuekyrl9K5hH5rYmRu9kRJSPt0HyNxUYGe+cce6afiHEX5tDTI7qp5dmKWp8m47mF5jTEhAqxi2fShrgzye0Rq05DAqYQAYkXIVJQeFMuJNyJhhyhScCk7FSocPv9dxAv5cdijBTdR3g1seIM8xi1UX50Igi9vMfTc= 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=i29WOvWa; arc=none smtp.client-ip=192.198.163.13 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="i29WOvWa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489782; x=1759025782; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=IbCXass7UYncWYJbpbqgopMF9OvpwOCCnOnS4dLfg9g=; b=i29WOvWaY7ctZ5hkt2fqkB7TYORQUUNb/qxfD3CIr4arOMfsuK7o186h 8XQEMoXFBsymLHLCxJP9XtC2xDAPXpJ1Wg+Vs2AG3Q1uBkbcwmS7DVJmY POze6vmN5Eye6zJeEMBlO2EsVML7FYxhNN0mBwO6LjZtCowCZL0V6CW+K DIUEHr+C6/vWvUIhHLfgb5szOO9kY+2gSlOviLMxJAvWDthDOKJwVnu7r 1O032+Kg+7aPqgg9DMSiXkk0MrrOuO8BazUjD4IdgFQFGzBB4XOtXsqE3 5Zkj2Lvi0TyrKaLfnTilaDjDW2n3a7du8+FGsp79+hIAePUwvygtnaPS1 g==; X-CSE-ConnectionGUID: 4NppqdQ4QU2DQAfQcqgnNg== X-CSE-MsgGUID: PafqYNasQG+PV4C3NtFuyA== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526863" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526863" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:20 -0700 X-CSE-ConnectionGUID: 7MNZVH/3QTSILL+XMnuEgg== X-CSE-MsgGUID: oL3sghaCRXW2zPSVQBV2gQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507110" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 1/8] mm: Define obj_cgroup_get() if CONFIG_MEMCG is not defined. Date: Fri, 27 Sep 2024 19:16:13 -0700 Message-Id: <20240928021620.8369-2-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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 resolves an issue with obj_cgroup_get() not being defined if CONFIG_MEMCG is not defined. Before this patch, we would see build errors if obj_cgroup_get() is called from code that is agnostic of CONFIG_MEMCG. The zswap_store() changes for large folios in subsequent commits will require the use of obj_cgroup_get() in zswap code that falls into this category. Signed-off-by: Kanchana P Sridhar Reviewed-by: Nhat Pham Acked-by: Johannes Weiner Reviewed-by: Chengming Zhou Reviewed-by: Yosry Ahmed --- include/linux/memcontrol.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 34d2da05f2f1..15c2716f9aa3 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1282,6 +1282,10 @@ struct mem_cgroup *mem_cgroup_from_css(struct cgroup= _subsys_state *css) return NULL; } =20 +static inline void obj_cgroup_get(struct obj_cgroup *objcg) +{ +} + static inline void obj_cgroup_put(struct obj_cgroup *objcg) { } --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 2936023774 for ; Sat, 28 Sep 2024 02:16:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489788; cv=none; b=kN/5DzL6bpvVZR/k58RMNGI7/Q5zjLN7ychCTAzP2D/x/TUeneURvOTHa3tamNlZbd3Rn4cImgij+8Beek3M2aH+fVM2eJ/SkQp0v0hIEUvqC1NVpbFJZVClLoZ83nG92GVO+wEAmzzdVJFFyz3Ld5dOENJnQwXrqrUTGtxqDqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489788; c=relaxed/simple; bh=KQeyC+P/mFswkiAsqAghN2A7u1uS+p3jOQ5BMPTPZHI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=N3DkZ9srMzuZ17DeuHe6xcVoDw9+2V9st4NnYQ+E0kplnMnWx/MUMFgojGewhM+gOTNfdOliOY8TjeEmCAiVkbVGS1jDkOtMlqCkst/veVIim8Leq0cPUYUjVTbEw/5O7kL2+CDo1XMAwxxq0txFyZwvDoDSZ4RZ5vg4RuN9T8M= 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=YH2cKeBL; arc=none smtp.client-ip=192.198.163.13 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="YH2cKeBL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489787; x=1759025787; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KQeyC+P/mFswkiAsqAghN2A7u1uS+p3jOQ5BMPTPZHI=; b=YH2cKeBLZrGltcyHtJ+7x8MVwEcIIJQ42swmMevMGcgo8/fwBx3Qj9Hg n5kHyTMoecNvQ7hO29xh15Vm++CufthLhybgo3OMLhsd8lxotFc+HFOoz 0aw0ZQzH7wOdBZB/Rpxq0drT5a4NtPlZZLs/h6NSakTWENKRTqUkg7Y99 NsYu1Ta7Nn0ZB8Fv+UlERddNBDKI+WzvkL6QWKkL1Ax48Nd48E+pT7hrk l6EugPId70HSEmsvEta1vcRZZtz1qZ+1sb8hMLVA+QKfQaKkOjHl8CyyX /xC1IjrbECMwpjJONC7P7EiK6aV//lXkPXqFGbtpULvGjSGLC9kWX5ndr Q==; X-CSE-ConnectionGUID: nMcNcxSdTfO/LnWhiyn2mw== X-CSE-MsgGUID: 2CSFJoGeTB+V4tMw3O5TvA== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526869" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526869" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: n4rSEBVmS3m1aY2A58DlMA== X-CSE-MsgGUID: WdeSY2XgRu25oGb8CioSBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507114" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 2/8] mm: zswap: Modify zswap_compress() to accept a page instead of a folio. Date: Fri, 27 Sep 2024 19:16:14 -0700 Message-Id: <20240928021620.8369-3-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" For zswap_store() to be able to store a large folio by compressing it one page at a time, zswap_compress() needs to accept a page as input. This will allow us to iterate through each page in the folio in zswap_store(), compress it and store it in the zpool. Signed-off-by: Kanchana P Sridhar Reviewed-by: Nhat Pham Acked-by: Johannes Weiner Reviewed-by: Chengming Zhou --- mm/zswap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index efad4e941e44..fd7a8c14457a 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -875,7 +875,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; @@ -893,7 +893,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, @@ -1456,7 +1456,7 @@ bool zswap_store(struct folio *folio) mem_cgroup_put(memcg); } =20 - if (!zswap_compress(folio, entry)) + if (!zswap_compress(&folio->page, entry)) goto put_pool; =20 entry->swpentry =3D swp; --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 41FB31C286 for ; Sat, 28 Sep 2024 02:16:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489787; cv=none; b=hKXE1w1Yyda49LweQ+ylnAgD80PLSIrWDKXL0btpY5fqq06pjB4L+b3fUs9aADYz1qLDYSYsfcqz8SA1ZlstgHQyCnGSAFy3hKB9w0qBPa1z78opObHC2pcjLQHEevwKRmTHT8bj3+bFWn6+V2HtqbZsE3znYHonCSKU7WnrCNg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489787; c=relaxed/simple; bh=/WDA8F+aPpzJk3yIqLIwiWFiov3kl+WxDzwsHsiRG30=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=g1emX7miWVZEFmiycLC3kedBToqpmA/2FDBIVvRLs4mIoxVuda0mufVc8yq3rDi0+nwKPEK9bmapxJagt+6NIkDUATwuNQxpLCR9QbTkJlU43wmeT8eBUqHfQI5FUiREm2c+Jm40gdRnrptpdhfcwsb7PIifEsDH46T8rqaIKbY= 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=Lw1e5ogQ; arc=none smtp.client-ip=192.198.163.13 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="Lw1e5ogQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489785; x=1759025785; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/WDA8F+aPpzJk3yIqLIwiWFiov3kl+WxDzwsHsiRG30=; b=Lw1e5ogQ09COCWG4Q3ij/cExfzmu1au+xeO/bccIRuZqlnnaVK9tzA60 4cN2lSBdpVdfooYo1mhVVML9xpOYKcTnPDmA6omEMgvGVqLcaH4zbpDhZ HNoIUgVWy6Z4dSqz/CwiFiHR9IdUy5LbPxtzXLpEVu133zQrpHal81Qvl Jkx5iLzQbKyowCr54NVIxpXbDb66Pf3h2jXZ7BKum+74yLD9hfy4T5WuW U5JPzKBiyudT0ss7BnY9YTtfoTHfUC8CqMFwqmDj4unn1cfrP5EfCIQAN mhBxGpJ53sxNXf/Km3Cc5YSlXdPBDLf1uD1lXUaGSl86d4ffINGHeDfmr g==; X-CSE-ConnectionGUID: 52O2MEFQQ4aGqwncK01rBg== X-CSE-MsgGUID: zgoFGUyMQcCAVrilnnPsPg== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526875" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526875" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: H4RpcxvRRyKCBU3hp5OkjA== X-CSE-MsgGUID: hIO6QzIVRNS6vQR5jZoNyA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507119" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 3/8] mm: zswap: Rename zswap_pool_get() to zswap_pool_tryget(). Date: Fri, 27 Sep 2024 19:16:15 -0700 Message-Id: <20240928021620.8369-4-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" Modify the name of the existing zswap_pool_get() to zswap_pool_tryget() to be representative of the call it makes to percpu_ref_tryget(). A subsequent patch will introduce a new zswap_pool_get() that calls percpu_ref_get(). The intent behind this change is for higher level zswap API such as zswap_store() to call zswap_pool_tryget() to check upfront if the pool's refcount is "0" (which means it could be getting destroyed) and to handle this as an error condition. zswap_store() would proceed only if zswap_pool_tryget() returns success, and any additional pool refcounts that need to be obtained for compressing sub-pages in a large folio could simply call zswap_pool_get(). Signed-off-by: Kanchana P Sridhar Acked-by: Johannes Weiner Acked-by: Yosry Ahmed Reviewed-by: Chengming Zhou Reviewed-by: Nhat Pham --- mm/zswap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index fd7a8c14457a..0f281e50a034 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -403,7 +403,7 @@ static void __zswap_pool_empty(struct percpu_ref *ref) spin_unlock_bh(&zswap_pools_lock); } =20 -static int __must_check zswap_pool_get(struct zswap_pool *pool) +static int __must_check zswap_pool_tryget(struct zswap_pool *pool) { if (!pool) return 0; @@ -441,7 +441,7 @@ static struct zswap_pool *zswap_pool_current_get(void) rcu_read_lock(); =20 pool =3D __zswap_pool_current(); - if (!zswap_pool_get(pool)) + if (!zswap_pool_tryget(pool)) pool =3D NULL; =20 rcu_read_unlock(); @@ -462,7 +462,7 @@ static struct zswap_pool *zswap_pool_find_get(char *typ= e, char *compressor) if (strcmp(zpool_get_type(pool->zpool), type)) continue; /* if we can't get it, it's about to be destroyed */ - if (!zswap_pool_get(pool)) + if (!zswap_pool_tryget(pool)) continue; return pool; } --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 5618238389 for ; Sat, 28 Sep 2024 02:16:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489788; cv=none; b=LNltF+ij/lg7CBrEuifdKlX283700JsqzZV3IfUsRKZnOfLuxPbnkTJzHUN7/wsnji0lDYlmuwV9l77P7+mND6sPdjHkxlf/Qk1o7tS0Ep0/LgEB6tX3JZ4UJ+P/AXk1rF9Tmd7wBU+FAEEMWZolHPOgjMyVCNJvywiYZF1r004= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489788; c=relaxed/simple; bh=QHKnkJGGdaPi/P8pWr1YVsvSRJmDf6+suHy+r3IyAYQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ckR6tnlGFiiPoZIUgzCMFcCYpEvgdPjEDXipQiTqZ+xlz1GAUDKiEAP/CqBKNt9RXA+T6SA++7IZkuT8CsirFya2D8k/8OTADDbWAEYWGYa9lW3jL7ntvE6zVXXIKCBYCDS/96RHwmSluF/N9b/8nJlwgyIWgbUJQJBnfD19aTk= 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=HTm0byvn; arc=none smtp.client-ip=192.198.163.13 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="HTm0byvn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489787; x=1759025787; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QHKnkJGGdaPi/P8pWr1YVsvSRJmDf6+suHy+r3IyAYQ=; b=HTm0byvnzXkP9HeJ92lpTpdGE2YxqttyZb5Xz4VFHy987RZgNL8Lt4h8 Pxzqiygb/TQLYw2RknEj1qMzJX1wKyuXW8nALWffbEGx5Tkc+HYF9bG4B oG2Cn6Cxnr+RccZvyNBOiFafvhMhn+8yiRi+1fMe7B9rlXz0xaA4E8U5z ZU3PXrqSpMko+Y0gu8OayKOm0W0J/SteSfjIFRvxdQoclqXlyB7Jzcyvj KtLHeb3xTGRLPQ9Lo5SdNRaVz9Dq4jwQfEw1+P5Mm+Y0OwrThCYvXvSh6 nbZrXBuYbLNFW8Ai+JUHhP7tg0pX3L3lDoReL4nOktd7kegc0Ww8SU9m9 A==; X-CSE-ConnectionGUID: Q/8KffVeRXiZNplaLzrckA== X-CSE-MsgGUID: mtULPFWtSeCe88QxYczbJQ== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526884" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526884" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: NLInsGB0QhKm+ll4bJ7x3w== X-CSE-MsgGUID: VaCbO+f5T0Sm7iNs63SZkw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507123" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 4/8] mm: Provide a new count_objcg_events() API for batch event updates. Date: Fri, 27 Sep 2024 19:16:16 -0700 Message-Id: <20240928021620.8369-5-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" With the introduction of zswap_store() swapping out large folios, we need to efficiently update the objcg's memcg events once per successfully stored folio. For instance, the 'ZSWPOUT' event needs to be incremented by folio_nr_pages(). Signed-off-by: Kanchana P Sridhar --- include/linux/memcontrol.h | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 15c2716f9aa3..f47fd00c5eea 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1778,6 +1778,21 @@ static inline void count_objcg_event(struct obj_cgro= up *objcg, rcu_read_unlock(); } =20 +static inline void count_objcg_events(struct obj_cgroup *objcg, + enum vm_event_item idx, + unsigned long count) +{ + struct mem_cgroup *memcg; + + if (!memcg_kmem_online()) + return; + + rcu_read_lock(); + memcg =3D obj_cgroup_memcg(objcg); + count_memcg_events(memcg, idx, count); + rcu_read_unlock(); +} + #else static inline bool mem_cgroup_kmem_disabled(void) { @@ -1834,6 +1849,11 @@ static inline void count_objcg_event(struct obj_cgro= up *objcg, { } =20 +static inline void count_objcg_events(struct obj_cgroup *objcg, + enum vm_event_item idx, + unsigned long count) +{ +} #endif /* CONFIG_MEMCG */ =20 #if defined(CONFIG_MEMCG) && defined(CONFIG_ZSWAP) --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 AD0C52FB6 for ; Sat, 28 Sep 2024 02:16:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489789; cv=none; b=b9jBDGumVOY437CeajEuCur2vjTyGXN0N+d/bRESel18j3nu34QDREAbWudw6GrggDzM3KKZdrPRLO31CGWHR/alKvKfmk8ktAitIF0c2MhnybJ7YY+60SoYxJjj9ixWqW4lVFy7C8ol1ThxKKyIg4d6LbmiJmGJ5SGy4sjH6Mw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489789; c=relaxed/simple; bh=7AZStRs4Lxum8UQacAgZWzRz8QxxXzYiQ2pEjwK5j3g=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=iSUkQUXfmAVkTSULbk6rV9ooLUh2ZkxG93CMAyutsZcCxhBp5RdyBDPfAYsZPA2VyoJks4puFc7w9WzCYJV55I5c6Exy9ZUrLk9utuwBXtyUrNSkg5eqIeieFbahoiCjwUcw9ACuYN+VNdnICi/LCqD+rDHQm3nOXB7dQPwD7hw= 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=nHc/sPCj; arc=none smtp.client-ip=192.198.163.13 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="nHc/sPCj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489787; x=1759025787; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7AZStRs4Lxum8UQacAgZWzRz8QxxXzYiQ2pEjwK5j3g=; b=nHc/sPCj6bnl60olaesxAZPUqsUaJpRDRNQreFy0bui9OmdwkQy8fMVy vAbFJZMsH6j5TUK5/+AhypmYoKhZPuJikDHg0L0aB6KJzhd2ppUp6vFL/ iDXT0A9hZdq/Gp3cx3auPIRka5EV7T5YsFU34nDZ3JyUSjdBR+aTsq0nt AIpnby8kPJoeFndo6p3Wn/i8m6kZP1XQSjRz4gLx6tiygM7WLTAtAdJGe 001OGpNb40Y3PxyNa+16tn+SUw5D7LbVBa4TxHtCb8keRDrWcPrw9PTmG iDI/shgYfFgg4B6DeaBCjLyKOQCSTqNZ+SiqJDazs4X5fL6NVHErB9BqO w==; X-CSE-ConnectionGUID: iCJnneY3SWqH/ouuIGN40w== X-CSE-MsgGUID: OiyhXdC3QR+yIQ0ay12Rkw== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526893" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526893" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: mDT8is80RWObT6fFc36rng== X-CSE-MsgGUID: ugrimwV2TuCBBwZcCwdPzw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507127" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 5/8] mm: zswap: Modify zswap_stored_pages to be atomic_long_t. Date: Fri, 27 Sep 2024 19:16:17 -0700 Message-Id: <20240928021620.8369-6-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" For zswap_store() to support large folios, we need to be able to do a batch update of zswap_stored_pages upon successful store of all pages in the folio. For this, we need to add folio_nr_pages(), which returns a long, to zswap_stored_pages. Signed-off-by: Kanchana P Sridhar Acked-by: Johannes Weiner Acked-by: Yosry Ahmed Reviewed-by: Nhat Pham --- fs/proc/meminfo.c | 2 +- include/linux/zswap.h | 2 +- mm/zswap.c | 19 +++++++++++++------ 3 files changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c index 245171d9164b..8ba9b1472390 100644 --- a/fs/proc/meminfo.c +++ b/fs/proc/meminfo.c @@ -91,7 +91,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v) #ifdef CONFIG_ZSWAP show_val_kb(m, "Zswap: ", zswap_total_pages()); seq_printf(m, "Zswapped: %8lu kB\n", - (unsigned long)atomic_read(&zswap_stored_pages) << + (unsigned long)atomic_long_read(&zswap_stored_pages) << (PAGE_SHIFT - 10)); #endif show_val_kb(m, "Dirty: ", diff --git a/include/linux/zswap.h b/include/linux/zswap.h index 9cd1beef0654..d961ead91bf1 100644 --- a/include/linux/zswap.h +++ b/include/linux/zswap.h @@ -7,7 +7,7 @@ =20 struct lruvec; =20 -extern atomic_t zswap_stored_pages; +extern atomic_long_t zswap_stored_pages; =20 #ifdef CONFIG_ZSWAP =20 diff --git a/mm/zswap.c b/mm/zswap.c index 0f281e50a034..43e4e216db41 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -43,7 +43,7 @@ * statistics **********************************/ /* The number of compressed pages currently stored in zswap */ -atomic_t zswap_stored_pages =3D ATOMIC_INIT(0); +atomic_long_t zswap_stored_pages =3D ATOMIC_INIT(0); =20 /* * The statistics below are not protected from concurrent access for @@ -802,7 +802,7 @@ static void zswap_entry_free(struct zswap_entry *entry) obj_cgroup_put(entry->objcg); } zswap_entry_cache_free(entry); - atomic_dec(&zswap_stored_pages); + atomic_long_dec(&zswap_stored_pages); } =20 /********************************* @@ -1232,7 +1232,7 @@ static unsigned long zswap_shrinker_count(struct shri= nker *shrinker, nr_stored =3D memcg_page_state(memcg, MEMCG_ZSWAPPED); } else { nr_backing =3D zswap_total_pages(); - nr_stored =3D atomic_read(&zswap_stored_pages); + nr_stored =3D atomic_long_read(&zswap_stored_pages); } =20 if (!nr_stored) @@ -1501,7 +1501,7 @@ bool zswap_store(struct folio *folio) } =20 /* update stats */ - atomic_inc(&zswap_stored_pages); + atomic_long_inc(&zswap_stored_pages); count_vm_event(ZSWPOUT); =20 return true; @@ -1650,6 +1650,13 @@ static int debugfs_get_total_size(void *data, u64 *v= al) } DEFINE_DEBUGFS_ATTRIBUTE(total_size_fops, debugfs_get_total_size, NULL, "%= llu\n"); =20 +static int debugfs_get_stored_pages(void *data, u64 *val) +{ + *val =3D atomic_long_read(&zswap_stored_pages); + return 0; +} +DEFINE_DEBUGFS_ATTRIBUTE(stored_pages_fops, debugfs_get_stored_pages, NULL= , "%llu\n"); + static int zswap_debugfs_init(void) { if (!debugfs_initialized()) @@ -1673,8 +1680,8 @@ static int zswap_debugfs_init(void) zswap_debugfs_root, &zswap_written_back_pages); debugfs_create_file("pool_total_size", 0444, zswap_debugfs_root, NULL, &total_size_fops); - debugfs_create_atomic_t("stored_pages", 0444, - zswap_debugfs_root, &zswap_stored_pages); + debugfs_create_file("stored_pages", 0444, + zswap_debugfs_root, NULL, &stored_pages_fops); =20 return 0; } --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 CC338446B4 for ; Sat, 28 Sep 2024 02:16:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489790; cv=none; b=kWGQeVUXQpGU46Q9w2qIqBufUWdfVft0A6n2SCPrp3ZapqVSCI7PAaPZxPI3HgsIJibWcFjjIuVWt6nYYdrK3dXbOAP6yx6Gs9AsBSaZDg0KTB+KlvT6IbI+zc7uBEKfPOPgzDizLyp9LJF8E7Wa8NfjLdSXl3yh0lklbdJJce4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489790; c=relaxed/simple; bh=kXk6Ax7R4cbxIDcNNxyrrGN3X0TYFfUEAYtvllXSW9Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gNN4oc0go7/AGD5KjR1/n3IH5wh8MvUWAkvXTzfNwvwF1GANCUCcWVA6WPwcA/i+qzloK2P9oWZ6FGthB3ur6Lq0sQZCHv6iJiIlsf843pjMynDpCalB4/Vt7uGbyGtu6Km5eMYo0B47DscIZrSgcqftDv03QY6sPkIrv9oyDE4= 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=Rfn3NHwq; arc=none smtp.client-ip=192.198.163.13 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="Rfn3NHwq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489788; x=1759025788; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kXk6Ax7R4cbxIDcNNxyrrGN3X0TYFfUEAYtvllXSW9Y=; b=Rfn3NHwqoPopFDyCjsxAc1i9lyYJoYCF65uQw7D9O9Cq6y80phkqfs9g doYIrZebE5a7chPybxMpAo1gWv7w62vTdX7fvi2nBLqzy9yu8T7HunyhY JR5aebxvG6EFNfj6U+3GUHpdpUUGICm3QEImOYkvy9uFjg9LlwBOd6SIS Q3cmQcbiyw6/Pb07iI9GxaauebnGE5iyUoWlGhWj/Q2g6OfRJ4wC+SM19 Y1CJQb8DD9oTpsfvzIDEBwY7YQi/HOesINhxksp/vrHo2PE9Ox+e79W5i 28ncGt8v6jOx3jmxGLlLAcgoYXd/+U/oGv8ZMt+w4+yU6lbm0aqeKHe2R w==; X-CSE-ConnectionGUID: gAVMgcGfQ6mCCNskOU6v4w== X-CSE-MsgGUID: fEGVS6MOQhGFMSwAMTfdvg== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526902" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526902" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: 4AIpJFJWT46k/1SWK+nriw== X-CSE-MsgGUID: JE3lrKiySlCTp6DoWlx+Ww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507130" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 6/8] mm: zswap: Support large folios in zswap_store(). Date: Fri, 27 Sep 2024 19:16:18 -0700 Message-Id: <20240928021620.8369-7-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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 store large folios by compressing them page by page. This patch provides a sequential implementation of storing a large folio 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. We check the cgroup zswap limit and the zpool utilization against the zswap max/accept_threshold limits once, at the beginning of zswap_store. We also obtain a percpu_ref_tryget() reference to the current zswap_pool at the start of zswap_store to prevent it from being deleted while the folio is being stored. If these one-time checks pass, we compress the sub-pages of the folio, while maintaining a running count of compressed bytes for all the folio's sub-pages. If all pages are successfully compressed and stored, we do the cgroup zswap charging with the total compressed bytes, and batch update the zswap_stored_pages atomic/zswpout event stats with folio_nr_pages() once, before returning from zswap_store. The patch adds a new zswap_pool_get() function that is called in the sub-page level "zswap_store_page()" function. If an error is encountered during the store of any page in the folio, all pages in that folio currently stored in zswap will be invalidated. Thus, a folio is either entirely stored in zswap, or entirely not stored in zswap. This patch forms the basis for building compress batching of pages in a large folio in zswap_store by compressing up to say, 8 pages of the folio in parallel in hardware using the Intel In-Memory Analytics Accelerator (Intel IAA). 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 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 | 227 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 165 insertions(+), 62 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index 43e4e216db41..b8395ddf7b7c 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -411,6 +411,16 @@ static int __must_check zswap_pool_tryget(struct zswap= _pool *pool) return percpu_ref_tryget(&pool->ref); } =20 +/* + * Note: zswap_pool_get() should only be called after zswap_pool_tryget() + * returns success. zswap_pool_tryget() returns success only if the "pool"= is + * non-NULL and the "&pool->ref" is non-0. + */ +static void zswap_pool_get(struct zswap_pool *pool) +{ + percpu_ref_get(&pool->ref); +} + static void zswap_pool_put(struct zswap_pool *pool) { percpu_ref_put(&pool->ref); @@ -1402,38 +1412,35 @@ static void shrink_worker(struct work_struct *w) /********************************* * main API **********************************/ -bool zswap_store(struct folio *folio) + +/* + * Stores the page at specified "index" in a folio. + * + * @folio: The folio to store in zswap. + * @index: Index into the page in the folio that this function will store. + * @objcg: The folio's objcg. + * @pool: The zswap_pool to store the compressed data for the page. + * The caller should have obtained a reference to a valid + * zswap_pool by calling zswap_pool_tryget(), to pass as this + * argument. + * @compressed_bytes: The compressed entry->length value is added + * to this, so that the caller can get the total + * compressed lengths of all sub-pages in a folio. + */ +static bool zswap_store_page(struct folio *folio, long index, + struct obj_cgroup *objcg, + struct zswap_pool *pool, + size_t *compressed_bytes) { + struct page *page =3D folio_page(folio, index); swp_entry_t swp =3D folio->swap; - pgoff_t offset =3D swp_offset(swp); struct xarray *tree =3D swap_zswap_tree(swp); + pgoff_t offset =3D swp_offset(swp) + index; struct zswap_entry *entry, *old; - struct obj_cgroup *objcg =3D NULL; - struct mem_cgroup *memcg =3D NULL; - - VM_WARN_ON_ONCE(!folio_test_locked(folio)); - VM_WARN_ON_ONCE(!folio_test_swapcache(folio)); + int type =3D swp_type(swp); =20 - /* Large folios aren't supported */ - if (folio_test_large(folio)) - return false; - - if (!zswap_enabled) - goto check_old; - - /* 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); - } - - if (zswap_check_limits()) - goto reject; + if (objcg) + obj_cgroup_get(objcg); =20 /* allocate entry */ entry =3D zswap_entry_cache_alloc(GFP_KERNEL, folio_nid(folio)); @@ -1442,24 +1449,21 @@ bool zswap_store(struct folio *folio) goto reject; } =20 - /* if entry is successfully added, it keeps the reference */ - entry->pool =3D zswap_pool_current_get(); - if (!entry->pool) - goto freepage; + /* + * We get here only after the call to zswap_pool_tryget() in the + * caller, zswap_store(), has returned success. Hence it is safe + * to call zswap_pool_get(). + * + * if entry is successfully added, it keeps the reference + */ + zswap_pool_get(pool); =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->page, entry)) + if (!zswap_compress(page, entry)) goto put_pool; =20 - entry->swpentry =3D swp; + entry->swpentry =3D swp_entry(type, offset); entry->objcg =3D objcg; entry->referenced =3D true; =20 @@ -1480,11 +1484,6 @@ bool zswap_store(struct folio *folio) if (old) zswap_entry_free(old); =20 - if (objcg) { - obj_cgroup_charge_zswap(objcg, entry->length); - count_objcg_event(objcg, ZSWPOUT); - } - /* * We finish initializing the entry while it's already in xarray. * This is safe because: @@ -1496,36 +1495,140 @@ bool zswap_store(struct folio *folio) * an incoherent entry. */ if (entry->length) { + *compressed_bytes +=3D entry->length; INIT_LIST_HEAD(&entry->lru); zswap_lru_add(&zswap_list_lru, entry); } =20 - /* update stats */ - atomic_long_inc(&zswap_stored_pages); - count_vm_event(ZSWPOUT); - return true; =20 store_failed: zpool_free(entry->pool->zpool, entry->handle); put_pool: - zswap_pool_put(entry->pool); -freepage: + zswap_pool_put(pool); zswap_entry_cache_free(entry); reject: obj_cgroup_put(objcg); - if (zswap_pool_reached_full) - queue_work(shrink_wq, &zswap_shrink_work); -check_old: + return false; +} + +bool zswap_store(struct folio *folio) +{ + long nr_pages =3D folio_nr_pages(folio); + swp_entry_t swp =3D folio->swap; + struct xarray *tree =3D swap_zswap_tree(swp); + pgoff_t offset =3D swp_offset(swp); + struct obj_cgroup *objcg =3D NULL; + struct mem_cgroup *memcg =3D NULL; + struct zswap_pool *pool; + size_t compressed_bytes =3D 0; + 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 zswap limits: + * + * The cgroup zswap limit check is done once at the beginning of + * zswap_store(). The cgroup charging is done once, at the end + * of a successful folio store. What this means is, if the cgroup + * was within the zswap_max limit at the beginning of a large folio + * store, it could go over the limit by at most (HPAGE_PMD_NR - 1) + * pages. */ - 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); + } + + /* + * Check zpool utilization against zswap limits: + * + * The zswap zpool utilization is also checked against the limits + * just once, at the start of zswap_store(). If the check passes, + * any breaches of the limits set by zswap_max_pages() or + * zswap_accept_thr_pages() that may happen while storing this + * folio, will only be detected during the next call to + * zswap_store() by any process. + */ + 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 deleting all the pages for this folio + * currently in zswap. + */ + for (index =3D 0; index < nr_pages; ++index) { + if (!zswap_store_page(folio, index, objcg, pool, &compressed_bytes)) + goto put_pool; + } + + /* + * All pages in the folio have been successfully stored. + * Batch update the cgroup zswap charging, zswap_stored_page atomic, + * and ZSWPOUT event stats. + */ + if (objcg) { + obj_cgroup_charge_zswap(objcg, compressed_bytes); + count_objcg_events(objcg, ZSWPOUT, nr_pages); + } + + /* update stats */ + atomic_long_add(nr_pages, &zswap_stored_pages); + count_vm_events(ZSWPOUT, nr_pages); + + ret =3D true; + +put_pool: + zswap_pool_put(pool); +put_objcg: + obj_cgroup_put(objcg); +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) { + 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); + } + + if (zswap_pool_reached_full) + queue_work(shrink_wq, &zswap_shrink_work); + } + + return ret; } =20 bool zswap_load(struct folio *folio) --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 11F0E502BE for ; Sat, 28 Sep 2024 02:16:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489791; cv=none; b=a2VXusbvCdeFM6JAevBKqjZGzaiPfEhTOgKnTJ2bsRV15wb7iKdwwaJi28L4pj8c9MszSTuIP7vEbVwyf1wIw3OaUmg8ZkDbmgsq3t228Rjgh3NhvPSfF78dSZldX4sYRk7vI+voi6M4K4/DqzJ49dQnc+EUKfpzGmLWfMW2ivU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489791; c=relaxed/simple; bh=6AckfW5DPm7esIMMaP5o1qk+OTB0aCm1cTjPckojN8M=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pr/i0aaBwwgu+vKrtJsBUDdfwRR/CjRPO+jw+wGVYuqQkKm1kO7XePqn1afuvIrVNIjW0DYsraTa3x3WibEpp8q6TFdUrWbkSOno0wb2/sahQAtMJmd/EZ8q4KRm/63YydsAObqmwisyyjnY6qMXPom8Cq4ExFtx7YYyPLPdPMQ= 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=UvB5ob7Z; arc=none smtp.client-ip=192.198.163.13 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="UvB5ob7Z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489789; x=1759025789; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=6AckfW5DPm7esIMMaP5o1qk+OTB0aCm1cTjPckojN8M=; b=UvB5ob7ZFi2p2HvgryjnAGPsYsVXTKM4ewEDlunJ57qLVsEXS5H7vXnD oF7MfNgUFBRybHU3fvHG8E+axcuTXp8ds1ZyL9Sn+LdEVrWrZm1656Bxt oaCtImKp0WOCUnJs9mgAjo9J810NcodrTBypyLds8985MhoVCQeTZ0RSJ IiJasNRe2MxvVxu+MhKuQtrsmWEARGTm+qCsImWLuTIA+1mTd6+gF2TkB yVfEuYqDY/0CGmga7Fuk+zcv9oN0T7i2t3mRbQncuxeksi/dTraqZmmnY l16RODyPCbdduEPSxyIeEV/wQ8V4RA958vuTCjI4Llus7oFxbOJt/WC+p w==; X-CSE-ConnectionGUID: xc9fDNjoQtaF0xqdv49ODg== X-CSE-MsgGUID: caPuAJQASCKJwB597Xy2Rg== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526909" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526909" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: 7310gMP3QtWHwY/v2lB2jA== X-CSE-MsgGUID: A0YqRezoS0+mYDf5q/jI8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507133" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 7/8] mm: swap: Count successful large folio zswap stores in hugepage zswpout stats. Date: Fri, 27 Sep 2024 19:16:19 -0700 Message-Id: <20240928021620.8369-8-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" Added a new MTHP_STAT_ZSWPOUT entry to the sysfs transparent_hugepage stats so that successful large folio zswap stores can be accounted under the per-order sysfs "zswpout" stats: /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/zswpout Other non-zswap swap device 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 --- include/linux/huge_mm.h | 1 + mm/huge_memory.c | 3 +++ mm/page_io.c | 1 + 3 files changed, 5 insertions(+) diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 5eb4b0376c7d..3eca60f3d512 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -119,6 +119,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 13bf59b84075..f596f57a3a90 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -611,6 +611,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); #ifdef CONFIG_SHMEM @@ -629,6 +630,7 @@ static struct attribute *anon_stats_attrs[] =3D { &anon_fault_fallback_attr.attr, &anon_fault_fallback_charge_attr.attr, #ifndef CONFIG_SHMEM + &zswpout_attr.attr, &swpout_attr.attr, &swpout_fallback_attr.attr, #endif @@ -659,6 +661,7 @@ static struct attribute_group file_stats_attr_grp =3D { =20 static struct attribute *any_stats_attrs[] =3D { #ifdef CONFIG_SHMEM + &zswpout_attr.attr, &swpout_attr.attr, &swpout_fallback_attr.attr, #endif diff --git a/mm/page_io.c b/mm/page_io.c index bc1183299a7d..4aa34862676f 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -269,6 +269,7 @@ int swap_writepage(struct page *page, struct writeback_= control *wbc) swap_zeromap_folio_clear(folio); } if (zswap_store(folio)) { + count_mthp_stat(folio_order(folio), MTHP_STAT_ZSWPOUT); folio_unlock(folio); return 0; } --=20 2.27.0 From nobody Thu Nov 28 19:48:39 2024 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 A64F26F30C for ; Sat, 28 Sep 2024 02:16:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489791; cv=none; b=YXtBYI0bM8iSsCaM/fjH6pTGpNPfWg73ZqL2zluf/ljr7KrCFlr8LUiSOkM714THZ2WIgr2bGNb4Q/Cr7qWzmOk5h+osfiq/2xGx8mALw8Wgs9MlumA5ucyIkfE99TyESyIi2QvhksYsJZlbK1TH1v7rJt86hPoTX3aV+7ufZC0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727489791; c=relaxed/simple; bh=jeCu3iqu/2EXy9IfjtlKEtm4q6TnkB4czmIDU7q2LAY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Nq55BZ4RKskcWxZhRu17OFaCjJqFegd4bKZE06AFSn7dXZlQWjkQjR82z95dlgHWCi9p9wpQsXnzx0856XcdBRuFHF+NVbuSTd82gZhOd7L4Oe9jc68x4CIb6ZY6O1rzwRgOI56Vc4Di34KJ3Gnb6sYwb1Nnf4GV3AqNObGvczA= 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=OectKrhh; arc=none smtp.client-ip=192.198.163.13 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="OectKrhh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727489789; x=1759025789; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jeCu3iqu/2EXy9IfjtlKEtm4q6TnkB4czmIDU7q2LAY=; b=OectKrhhRg2WkVuZe+l7FNj5RNL8WnT0uDFwSYZm5CB09PoWnMA55UB9 ph0PwZ45Q3qaqFLYMhGdsrIvY38h47bUEAgQU0Cg023O7CJIkjcC8qq8m vBIVUg5AUgBSAy4WzmpECgzPh68jSCIjNOowCZQ6Yl3I2YNX591EHmySf bu+a9sPix6xKExXwM92L6/xaZTNSx3eE1tQX1HGOB/sWratFEfa7zRhWX K5WNphOc8AETR+OjP/K8F6BfChXLs2JH+qxMGffdZL2/TVXsfQpWt4OjN uMF3qggHLKWUx9l1jUrVEadSPssC5WFT0HiCWJtVRx1AKj8jrQiqn3OJx Q==; X-CSE-ConnectionGUID: WpFbIHHWTkqjEoFx90ctZA== X-CSE-MsgGUID: k/PlLgqyRK6ucLhlYNeoKg== X-IronPort-AV: E=McAfee;i="6700,10204,11208"; a="29526918" X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="29526918" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2024 19:16:21 -0700 X-CSE-ConnectionGUID: cRQ5tnNWR5CUGZgxe6qXrg== X-CSE-MsgGUID: qgNMbP/jRMKqlKVlPbychw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,160,1725346800"; d="scan'208";a="73507136" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa008.jf.intel.com with ESMTP; 27 Sep 2024 19:16: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, 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 Cc: nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com, kanchana.p.sridhar@intel.com Subject: [PATCH v8 8/8] mm: Document the newly added sysfs large folios zswpout stats. Date: Fri, 27 Sep 2024 19:16:20 -0700 Message-Id: <20240928021620.8369-9-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> References: <20240928021620.8369-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" Added documentation for the newly added sysfs per-order hugepage "zswpout" stats. Clarified that only non-zswap swapouts will be accounted in the existing "swpout" stats. Signed-off-by: Kanchana P Sridhar Reviewed-by: Nhat Pham --- Documentation/admin-guide/mm/transhuge.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/adm= in-guide/mm/transhuge.rst index cfdd16a52e39..2a171ed5206e 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -530,10 +530,14 @@ anon_fault_fallback_charge instead falls back to using huge pages with lower orders or small pages even though the allocation was successful. =20 -swpout - is incremented every time a huge page is swapped out in one +zswpout + is incremented every time a huge page is swapped out to zswap in one piece without splitting. =20 +swpout + is incremented every time a huge page is swapped out to a non-zswap + swap device in one piece without splitting. + swpout_fallback is incremented if a huge page has to be split before swapout. Usually because failed to allocate some continuous swap space --=20 2.27.0