From patchwork Wed Aug 28 09:35:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kanchana P Sridhar X-Patchwork-Id: 13780968 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 6E5F0C5475C for ; Wed, 28 Aug 2024 09:35:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3ABC6B0092; Wed, 28 Aug 2024 05:35:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC3816B0093; Wed, 28 Aug 2024 05:35:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3C616B0095; Wed, 28 Aug 2024 05:35:21 -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 83AD76B0092 for ; Wed, 28 Aug 2024 05:35:21 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E1312161D8A for ; Wed, 28 Aug 2024 09:35:20 +0000 (UTC) X-FDA: 82501146000.26.4AE4C9A Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf22.hostedemail.com (Postfix) with ESMTP id B057CC0013 for ; Wed, 28 Aug 2024 09:35:18 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L7Uvi8VR; spf=pass (imf22.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724837632; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=zk7vyLj51jbESNm7GtKun0fUjFP2DXqlKxd3QGYack8=; b=orFz4Hz25Bs4vhSrODJbHDCXp24IZb5w1DjPX9UGMCDgUflrHP4wwgv1vHypdlo1CK7gbh 79wIOjSoirYKefoq0PxtNPyR/DSzsdpoosQ4f505zdD1Z997vf0kvWC/Hyhg1MHMO7TRzD 9m4LePRbS+Uyeg27+p0Q5Wow7Qa2qf8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724837632; a=rsa-sha256; cv=none; b=dksFl1rc2GJgKQ4j897ocesTRHZD3orOmqES+WCVaDKmviBMgpIxTO1V4XJveebMtzAwMd l0HD1IrJbv8aLHC7FzKmZHa2Z7nbI2HfmzCF1MFVY8plgtjci8JJ2K2d6gWbeHy0A2xV1v 8CkVBDfNHMCbOGUPGZM2n2HKno1VAiE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=L7Uvi8VR; spf=pass (imf22.hostedemail.com: domain of kanchana.p.sridhar@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=kanchana.p.sridhar@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724837719; x=1756373719; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=NiF62iqrn+9n4WBSVLYPTR6s9rULH31+2PcD1JYr8j0=; b=L7Uvi8VRF8G24oI26qcmZWWpUbkm2YTbvWulI55YFeyujFYOnLVXstEE YhuwlMqbgEV4UM5H1Xcih2SFtG/FOBkABOsCiOz1+9bpl3XR4cfj2wGPb 4APfbdAzJdkNWNHMMncxxuZr1v4Hzfp7EwZpUcIJZ+DubNrGSFdpq6kJf wayQdS/i6Q4iu3fw/yFVHcZrf9SoYlYIS7PLOgOGr+TPP1MRofX67rAJj 4Q1c8+Onrr3R/xczezlGjVEh2CoJmoMJcTfSPig78CoiPmVdcI62bXLW+ 1SNyQw3Rd/0BmfBETMHuPuzyJAYCM3+mYl7TVmhg4OF/F1YjbxOzC0StI g==; X-CSE-ConnectionGUID: MZ41MmHGRb6UscGRG91CBA== X-CSE-MsgGUID: 5kTClDm4SZyxcULh5/n5kQ== X-IronPort-AV: E=McAfee;i="6700,10204,11177"; a="34763859" X-IronPort-AV: E=Sophos;i="6.10,182,1719903600"; d="scan'208";a="34763859" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Aug 2024 02:35:16 -0700 X-CSE-ConnectionGUID: qGeCW/dXRRi/EhNod2q4Yw== X-CSE-MsgGUID: +12GoNPsS9aMVov/G3DhiA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,182,1719903600"; d="scan'208";a="100678968" Received: from jf5300-b11a338t.jf.intel.com ([10.242.51.6]) by orviesa001.jf.intel.com with ESMTP; 28 Aug 2024 02:35:16 -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 v5 0/3] mm: ZSWAP swap-out of mTHP folios Date: Wed, 28 Aug 2024 02:35:13 -0700 Message-Id: <20240828093516.30228-1-kanchana.p.sridhar@intel.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 X-Rspamd-Queue-Id: B057CC0013 X-Stat-Signature: f76f494cyjq61qaywoakx4qy3eusaosq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724837718-583359 X-HE-Meta: U2FsdGVkX18Dl82Pe8RPIDSD2U/kPkdmLVOAxAkctYVhVu2kOeCjfhQ3RDgFdDDo1KbbK5dGJ03vtw2AfdzrgZF5kkE7SI4p8ECgKFFagj8tXdpzRQPcRMOfzCriWRdhfh7AZbAvcHtj9pyEfSsz98GfAPxxub8CnLkcIthoFHoPVdpKBd8niIUiDbuphGnX9YAHCAM0PG/LBZlhrgc9pARdqeoyArGeCEsscr/v1ego7gTeHoLlyocOMstbXns2tAMoOy3/l31ccGOVQ6w+KZc6jupwCgTJbETEB+3pP9V7JJIt+lIU4pDJUmD4JG6bcRxpD4svxMfQwcEP6e/ptS+H0K1Kb97bTTE5Eqr1v5XlmgeDlvrR5e0xzFxWi7+0JkF0HHzGYTG16LngGqiYSI4xWopxsWkQuz4lz1G6NYA8rU1dmN0NZy9cXLdkCF56AJcM/COe6ME92HPPJn5WT885OUWme12Gz1qpxVZwSWeBKa53ICnVKShEdE/1hzGBsTRyORWdXzLG0p8M8fJFN6LYR+oTbWZeh+dtbKM2z5gVJEzxR87GwDaOISy5ypATVa9GMHulsxWyKIJsQbs10pf105q2peLyCEKW7nZ1dfkPhZ0C09PKui3B2/db3U7paiqaNLkuXRv9kUBjEj5tSD17nqJb0fGznkSIn+QEYKvkfkhOarPblITmmKZHfE+IxyhG1wiPF+qdjX7yO04PiujT2TtD6/IACg8QMEMBfLo/4b/X2Tlrnvp1LBNurqR6HuBlUapqb2iIxGVEGlXbmaoEoVQ4FgeRhJYN251Ul2eb7LwAeQvBtSz2RFFygVnbhr6ZlW+zFifDAOMPv/tYvZMR8+Aj5hFUPuS/rOmczAZCYUE8TihRPQd8v1xZ6O5A0itp8mGspdbeRRq5r73dqcCWVdEmgbByf2ZEW6kvhBMC1+F5AeumED8KJmEeNVrQfbwajqSvvp6GCvu46IK VLoGWuKe tZ0C+HeK9CS+KfR2oMXzfALnSiOvN/F5r/QaTbNlclmnRo5nlp7as/8AFiwDN2dq9Jyl2eWZqJgSfuROHgalm23aBiz18mOwTh5KJeW3vX688zgUKdxA+t1RlUWiEO95PkAlNTmuljCzoKq3zrHUs9sCi5pXrRQa6hdTJe5D8672TEDPFqgJBNVLcVJAMdKJXiwlgO7JEVFUkwd/e6NBPPzbd7/XUU0+FuaCDkW65QIBaC0sk1iMlrBLE9mj1pH+xyN6x58R9JoD0ctc3flHKrl2Cig== 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: Hi All, This patch-series enables zswap_store() to accept and store mTHP folios. The most significant contribution in this series is from the earlier RFC submitted by Ryan Roberts [1]. Ryan's original RFC has been migrated to v6.11-rc3 in patch 2/4 of this series. [1]: [RFC PATCH v1] mm: zswap: Store large folios without splitting https://lore.kernel.org/linux-mm/20231019110543.3284654-1-ryan.roberts@arm.com/T/#u Additionally, there is an attempt to modularize some of the functionality in zswap_store(), to make it more amenable to supporting any-order mTHPs. For instance, the function zswap_store_entry() stores a zswap_entry in the xarray. Likewise, zswap_delete_stored_offsets() can be used to delete all offsets corresponding to a higher order folio stored in zswap. For accounting purposes, the patch-series adds per-order mTHP sysfs "zswpout" counters that get incremented upon successful zswap_store of an mTHP folio: /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/zswpout This patch-series is a precursor to ZSWAP compress batching of mTHP swap-out and decompress batching of swap-ins based on swapin_readahead(), using Intel IAA hardware acceleration, which we would like to submit in subsequent RFC patch-series, with performance improvement data. Thanks to Ying Huang for pre-posting review feedback and suggestions! Changes since v4: ================= 1) Published before/after data with zstd, as suggested by Nhat (Thanks Nhat for the data reviews!). 2) Rebased to mm-unstable from 8/27/2024, commit b659edec079c90012cf8d05624e312d1062b8b87. 3) Incorporated the change in memcontrol.h that defines obj_cgroup_get() if CONFIG_MEMCG is not defined, to resolve build errors reported by kernel robot; as per Nhat's and Michal's suggestion to not require a separate patch to fix the build errors (thanks both!). 4) Deleted all same-filled folio processing in zswap_store() of mTHP, as suggested by Yosry (Thanks Yosry!). 5) Squashed the commits that define new mthp zswpout stat counters, and invoke count_mthp_stat() after successful zswap_store()s; into a single commit. Thanks Yosry for this suggestion! Changes since v3: ================= 1) Rebased to mm-unstable commit 8c0b4f7b65fd1ca7af01267f491e815a40d77444. Thanks to Barry for suggesting aligning with Ryan Roberts' latest changes to count_mthp_stat() so that it's always defined, even when THP is disabled. Barry, I have also made one other change in page_io.c where count_mthp_stat() is called by count_swpout_vm_event(). I would appreciate it if you can review this. Thanks! Hopefully this should resolve the kernel robot build errors. Changes since v2: ================= 1) Gathered usemem data using SSD as the backing swap device for zswap, as suggested by Ying Huang. Ying, I would appreciate it if you can review the latest data. Thanks! 2) Generated the base commit info in the patches to attempt to address the kernel test robot build errors. 3) No code changes to the individual patches themselves. Changes since RFC v1: ===================== 1) Use sysfs for zswpout mTHP stats, as per Barry Song's suggestion. Thanks Barry! 2) Addressed some of the code review comments that Nhat Pham provided in Ryan's initial RFC [1]: - Added a comment about the cgroup zswap limit checks occuring once per folio at the beginning of zswap_store(). Nhat, Ryan, please do let me know if the comments convey the summary from the RFC discussion. Thanks! - Posted data on running the cgroup suite's zswap kselftest. 3) Rebased to v6.11-rc3. 4) Gathered performance data with usemem and the rebased patch-series. Performance Testing: ==================== Testing of this patch-series was done with the v6.11-rc3 mainline, without and with this patch-series, on an Intel Sapphire Rapids server, dual-socket 56 cores per socket, 4 IAA devices per socket. The system has 503 GiB RAM, with 176GiB ZRAM (35% of available RAM) as the backing swap device for ZSWAP. zstd is configured as the ZRAM compressor. Core frequency was fixed at 2500MHz. The vm-scalability "usemem" test was run in a cgroup whose memory.high was fixed at 40G. The is no swap limit set for the cgroup. Following a similar methodology as in Ryan Roberts' "Swap-out mTHP without splitting" series [2], 70 usemem processes were run, each allocating and writing 1G of memory: usemem --init-time -w -O -n 70 1g The vm/sysfs mTHP stats included with the performance data provide details on the swapout activity to ZSWAP/swap. Other kernel configuration parameters: ZSWAP Compressors : zstd, deflate-iaa ZSWAP Allocator : zsmalloc SWAP page-cluster : 2 In the experiments where "deflate-iaa" is used as the ZSWAP compressor, IAA "compression verification" is enabled. Hence each IAA compression will be decompressed internally by the "iaa_crypto" driver, the crc-s returned by the hardware will be compared and errors reported in case of mismatches. Thus "deflate-iaa" helps ensure better data integrity as compared to the software compressors. Throughput is derived by averaging the individual 70 processes' throughputs reported by usemem. sys time is measured with perf. All data points are averaged across 3 runs. 64KB mTHP (cgroup memory.high set to 40G): ========================================== ------------------------------------------------------------------------------ v6.11-rc3 mainline zswap-mTHP Change wrt Baseline Baseline ------------------------------------------------------------------------------ ZSWAP compressor zstd deflate- zstd deflate- zstd deflate- iaa iaa iaa ------------------------------------------------------------------------------ Throughput (KB/s) 161,496 156,343 140,363 151,938 -13% -3% sys time (sec) 771.68 802.08 954.85 735.47 -24% 8% memcg_high 111,223 110,889 138,651 133,884 memcg_swap_high 0 0 0 0 memcg_swap_fail 0 0 0 0 pswpin 16 16 0 0 pswpout 7,471,472 7,527,963 0 0 zswpin 635 605 624 639 zswpout 1,509 1,478 9,453,761 9,385,910 thp_swpout 0 0 0 0 thp_swpout_ 0 0 0 0 fallback pgmajfault 3,616 3,430 4,633 3,611 ZSWPOUT-64kB n/a n/a 590,768 586,521 SWPOUT-64kB 466,967 470,498 0 0 ------------------------------------------------------------------------------ 2MB PMD-THP/2048K mTHP (cgroup memory.high set to 40G): ======================================================= ------------------------------------------------------------------------------ v6.11-rc3 mainline zswap-mTHP Change wrt Baseline Baseline ------------------------------------------------------------------------------ ZSWAP compressor zstd deflate- zstd deflate- zstd deflate- iaa iaa iaa ------------------------------------------------------------------------------ Throughput (KB/s) 192,164 194,643 165,005 174,536 -14% -10% sys time (sec) 823.55 830.42 801.72 676.65 3% 19% memcg_high 16,054 15,936 14,951 16,096 memcg_swap_high 0 0 0 0 memcg_swap_fail 0 0 0 0 pswpin 0 0 0 0 pswpout 8,629,248 8,628,907 0 0 zswpin 560 645 5,333 781 zswpout 1,416 1,503 8,546,895 9,355,760 thp_swpout 16,854 16,853 0 0 thp_swpout_ 0 0 0 0 fallback pgmajfault 3,341 3,574 8,139 3,582 ZSWPOUT-2048kB n/a n/a 16,684 18,270 SWPOUT-2048kB 16,854 16,853 0 0 ------------------------------------------------------------------------------ In the "Before" scenario, when zswap does not store mTHP, only allocations count towards the cgroup memory limit. However, in the "After" scenario, with the introduction of zswap_store() mTHP, both, allocations as well as the zswap compressed pool usage from all 70 processes are counted towards the memory limit. As a result, we see higher swapout activity in the "After" data. Hence, more time is spent doing reclaim as the zswap cgroup charge leads to more frequent memory.high breaches. This causes degradation in throughput and sys time with zswap mTHP, more so in case of zstd than deflate-iaa. Compress latency could play a part in this - when there is more swapout activity happening, a slower compressor would cause allocations to stall for any/all of the 70 processes. In my opinion, even though the test set up does not provide an accurate way for a direct before/after comparison (because of zswap usage being counted in cgroup, hence towards the memory.high), it still seems reasonable for zswap_store to support (m)THP, so that further performance improvements can be implemented. One of the ideas that has shown promise in our experiments is to improve ZSWAP mTHP store performance using batching. With IAA compress/decompress batching used in ZSWAP, we are able to demonstrate significant performance improvements and memory savings with IAA in scalability experiments, as compared to software compressors. We hope to submit this work as subsequent RFCs. I would greatly appreciate your code review comments and suggestions! Thanks, Kanchana [2] https://lore.kernel.org/linux-mm/20240408183946.2991168-1-ryan.roberts@arm.com/ Kanchana P Sridhar (3): mm: Define obj_cgroup_get() if CONFIG_MEMCG is not defined. mm: zswap: zswap_store() extended to handle mTHP folios. mm: swap: Count successful mTHP ZSWAP stores in sysfs mTHP zswpout stats. include/linux/huge_mm.h | 1 + include/linux/memcontrol.h | 4 + mm/huge_memory.c | 3 + mm/page_io.c | 3 +- mm/zswap.c | 231 +++++++++++++++++++++++++++---------- 5 files changed, 180 insertions(+), 62 deletions(-) base-commit: b659edec079c90012cf8d05624e312d1062b8b87