From patchwork Mon Mar 11 15:00:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryan Roberts X-Patchwork-Id: 13588932 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 BA402C54E58 for ; Mon, 11 Mar 2024 15:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA6C96B00AD; Mon, 11 Mar 2024 11:01:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B56E06B00AE; Mon, 11 Mar 2024 11:01:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A45776B00AF; Mon, 11 Mar 2024 11:01:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 91B266B00AD for ; Mon, 11 Mar 2024 11:01:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B8D7D80CB9 for ; Mon, 11 Mar 2024 15:01:21 +0000 (UTC) X-FDA: 81885071562.11.C3FBE9F Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 73A8A20042 for ; Mon, 11 Mar 2024 15:01:11 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710169271; 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; bh=XOPOBMUbQm0FXfyCQygTH6bXRUifm77iLvy1+KBjtHs=; b=XDaKXztztH1CvhX17a9D2ExirXqZdQ41CR6Z7p6u/3/XWvjYiSh9t2Jeua6VVEFjwM1m98 juuf0XEZSVSgaU1MfGCZTAHNWzGVtZuH0iVzfLYJdPlQIvDCIpeCqBUpPdFnce5S/NMESJ xGchtbLppebQ3+EPeQ/1A5nyyjiZ45Q= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710169271; a=rsa-sha256; cv=none; b=RHhH6agTK3EyYA48yhuxhtaeDXOxyYUbDUf6c5Xz7j5nc86VnPlnHt7Q3lAbRXHsD2p4XI NjeefnrJedxQ4+kziyHCGqRJySfSm4igoPZ0Eh3E5mOAFmpQKin/Q0kzN47/TH5yh+xze3 ruO2ugXHNpDaV2pXNKRvpumGzOQ5zsU= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0477DFEC; Mon, 11 Mar 2024 08:01:47 -0700 (PDT) Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com [10.1.196.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C45B3F64C; Mon, 11 Mar 2024 08:01:07 -0700 (PDT) From: Ryan Roberts To: Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , Barry Song <21cnbao@gmail.com>, Chris Li Cc: Ryan Roberts , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 0/6] Swap-out mTHP without splitting Date: Mon, 11 Mar 2024 15:00:52 +0000 Message-Id: <20240311150058.1122862-1-ryan.roberts@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 73A8A20042 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: djtii415jmw61bb4cxn1tuqcdf6p4t8j X-HE-Tag: 1710169270-860454 X-HE-Meta: U2FsdGVkX19vQGvVNKjpOgftVu9n5h50M/a6NPwpic+hH1Igzd2sE79GqkDLCmeneCdIn8Yzv/RqnpPks5AQ/3MaITcf5nzl7m9B4vE2BotwXILuOskM0FUDyy9/f2Qd0hYmokuCQQsFZEYuQB9FzybKweSJ74T15YvK2iRSJ3zL1ZoowLFMDonwJqRxbDH2/Ln99HZ7LcuRjCOxwA8cVxA7D/VAAN6L5tU0WQ+WwzqgYEBvQYYVXqlZ277J4jOFYVI/8n3SI1YN/aX3QP+b3llx/Ew1zOdpkQdRmPO2cIyNLCNdxbskK5LZzWm8dS7MXT/jjOcQh84q6k/XH59uCvs8ACOf85KJIHNj55SULOU/H7YAe9O8i0eJw7IyS6QboJvTBvZSTBvinHKGh9NKROh3JsToS7FInySh6WtoGswJh3idtdWesaHEe25Rzuu90gzugEWdlysdNwfjCeZR7qvlWstrEzWfgBvzSc4cFhVglcZlGyKJwya0JGGaM/sbwfJYFNFhTObFJFfL3bvC0+YtuAiJQhBLmWwnhZaSWU85/eoW3yYYRSRtJ51kYKfWA0xkl+PqHw/BtZwapYyVD2+mmLWxEMvgTZXR+mE/T6l+oPcoBz9LbsJkGdBSTO7f6wofTgaxuLfPF5AwnicudXFeaNpiOCPTj7aGwC+by9mxb6nb52jjBE7iwodVQBCjH8JMvSXOKkkqVn7/4IKulwKRxzXhOI0sUmp1uLMcMi9y+xo0/wUEjkhwEsZa9yWwO7DK6rYi0iOT5QpFOrqxiS9RVL/krTBSRKXpS1Yr13ZyZcllQZPZQnhL8+ecffE/U3SkR1MjwMvU4QQ8o0q/B7GZhIw6gOsj 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 series adds support for swapping out multi-size THP (mTHP) without needing to first split the large folio via split_huge_page_to_list_to_order(). It closely follows the approach already used to swap-out PMD-sized THP. There are a couple of reasons for swapping out mTHP without splitting: - Performance: It is expensive to split a large folio and under extreme memory pressure some workloads regressed performance when using 64K mTHP vs 4K small folios because of this extra cost in the swap-out path. This series not only eliminates the regression but makes it faster to swap out 64K mTHP vs 4K small folios. - Memory fragmentation avoidance: If we can avoid splitting a large folio memory is less likely to become fragmented, making it easier to re-allocate a large folio in future. - Performance: Enables a separate series [4] to swap-in whole mTHPs, which means we won't lose the TLB-efficiency benefits of mTHP once the memory has been through a swap cycle. I've done what I thought was the smallest change possible, and as a result, this approach is only employed when the swap is backed by a non-rotating block device (just as PMD-sized THP is supported today). Discussion against the RFC concluded that this is sufficient. Performance Testing =================== I've run some swap performance tests on Ampere Altra VM (arm64) with 8 CPUs. The VM is set up with a 35G block ram device as the swap device and the test is run from inside a memcg limited to 40G memory. I've then run `usemem` from vm-scalability with 70 processes, each allocating and writing 1G of memory. I've repeated everything 6 times and taken the mean performance improvement relative to 4K page baseline: | alloc size | baseline | + this series | | | v6.6-rc4+anonfolio | | |:-----------|--------------------:|--------------------:| | 4K Page | 0.0% | 1.4% | | 64K THP | -14.6% | 44.2% | | 2M THP | 87.4% | 97.7% | So with this change, the 64K swap performance goes from a 15% regression to a 44% improvement. 4K and 2M swap improves slightly too. This test also acts as a good stress test for swap and, more generally mm. A couple of existing bugs were found as a result [5] [6]. --- The series applies against mm-unstable (d7182786dd0a). Although I've additionally been running with a couple of extra fixes to avoid the issues at [6]. Changes since v3 [3] ==================== - Renamed SWAP_NEXT_NULL -> SWAP_NEXT_INVALID (per Huang, Ying) - Simplified max offset calculation (per Huang, Ying) - Reinstated struct percpu_cluster to contain per-cluster, per-order `next` offset (per Huang, Ying) - Removed swap_alloc_large() and merged its functionality into scan_swap_map_slots() (per Huang, Ying) - Avoid extra cost of folio ref and lock due to removal of CLUSTER_FLAG_HUGE by freeing swap entries in batches (see patch 2) (per DavidH) - vmscan splits folio if its partially mapped (per Barry Song, DavidH) - Avoid splitting in MADV_PAGEOUT path (per Barry Song) - Dropped "mm: swap: Simplify ssd behavior when scanner steals entry" patch since it's not actually a problem for THP as I first thought. Changes since v2 [2] ==================== - Reuse scan_swap_map_try_ssd_cluster() between order-0 and order > 0 allocation. This required some refactoring to make everything work nicely (new patches 2 and 3). - Fix bug where nr_swap_pages would say there are pages available but the scanner would not be able to allocate them because they were reserved for the per-cpu allocator. We now allow stealing of order-0 entries from the high order per-cpu clusters (in addition to exisiting stealing from order-0 per-cpu clusters). Changes since v1 [1] ==================== - patch 1: - Use cluster_set_count() instead of cluster_set_count_flag() in swap_alloc_cluster() since we no longer have any flag to set. I was unable to kill cluster_set_count_flag() as proposed against v1 as other call sites depend explicitly setting flags to 0. - patch 2: - Moved large_next[] array into percpu_cluster to make it per-cpu (recommended by Huang, Ying). - large_next[] array is dynamically allocated because PMD_ORDER is not compile-time constant for powerpc (fixes build error). [1] https://lore.kernel.org/linux-mm/20231010142111.3997780-1-ryan.roberts@arm.com/ [2] https://lore.kernel.org/linux-mm/20231017161302.2518826-1-ryan.roberts@arm.com/ [3] https://lore.kernel.org/linux-mm/20231025144546.577640-1-ryan.roberts@arm.com/ [4] https://lore.kernel.org/linux-mm/20240304081348.197341-1-21cnbao@gmail.com/ [5] https://lore.kernel.org/linux-mm/20240311084426.447164-1-ying.huang@intel.com/ [6] https://lore.kernel.org/linux-mm/79dad067-1d26-4867-8eb1-941277b9a77b@arm.com/ Thanks, Ryan Ryan Roberts (6): mm: swap: Remove CLUSTER_FLAG_HUGE from swap_cluster_info:flags mm: swap: free_swap_and_cache_nr() as batched free_swap_and_cache() mm: swap: Simplify struct percpu_cluster mm: swap: Allow storage of all mTHP orders mm: vmscan: Avoid split during shrink_folio_list() mm: madvise: Avoid split during MADV_PAGEOUT and MADV_COLD include/linux/pgtable.h | 28 ++++ include/linux/swap.h | 33 +++-- mm/huge_memory.c | 3 - mm/internal.h | 48 +++++++ mm/madvise.c | 101 ++++++++------ mm/memory.c | 13 +- mm/swapfile.c | 298 ++++++++++++++++++++++------------------ mm/vmscan.c | 9 +- 8 files changed, 332 insertions(+), 201 deletions(-) -- 2.25.1