From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11010048.outbound.protection.outlook.com [52.101.61.48]) (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 A4B6D2EC0A7 for ; Mon, 27 Apr 2026 18:26:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.61.48 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777314382; cv=fail; b=WGFGDtE29+yKU4cD4fQBVSbQLrwTKSw++IvCE4g8EioU5RrqJZuTOnwDEKGyCBKVW0qkdv0u4aINVGSAL2/TrdSXfqQXj15+Lpp3bLMD3UNZfUCHHHVfz+Si4u3G9/kyh5Q7LKCzUdOs514ehoyICrIlHaCN8YD95M7KqzULMvo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777314382; c=relaxed/simple; bh=XVMSDrkaiMKvqFOMR2XUVLzeU6CxOBQE0P+w88m39/8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=jK5RWqzQaELvp+K5um2HcXB8+FhEH+avggpn/bpD6qPOTQBhD6IaJr0xYzeyoQ7pe8az7sXb11GwC9hOmNFpUmm3lLtyDRURrst7Jv4InCgsB8x+xTiINTBgNjrfkQlLnbvVp4YhrX5c4DmQbWuB0KIXOfOK2JC8pCGKDz/W2WE= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=mnWEbPN2; arc=fail smtp.client-ip=52.101.61.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="mnWEbPN2" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mAfLA5Bn1x24i07lWo6KlUXxzFQvk6rwPRBAW6eYWWplGjuJtFJKapHTgJm+tza0w+tT1bT4/CeD4845rEwCzTplEZv8GR8oRoIrBqbd5rHXmWJgU/m/hR3ABK42Lg7LXQTriKZ+GsscEBAceI1acWvRsr+kdvXqxGpDOCyZgSLBntMdDjx+Me/FylrS2GZ06JWhBpsChwZkf4G6cldoVWjNwNmD0B8Kv3xkMK+A6+0rs70YWWxw9pVuNahj2zQY0GU0Ak+MVbEO1mQTVcuVhA63qRZRfk8pVOb0cl0qENz2SxZ3xRc98lRqVrMAYd83Z4TOXrzGAv5ICqwkHFlERg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SXibD3dwhZtU8VXM3pFopcCZIopZpOmb+q0SJ2j4YUE=; b=RkhskiXYVxOZDoDr/U2SP19gZqlnK/SUPHCoJkVRiSe/M+VwkdkeWumWTNEJca3WPsasWdSZyhFHDgbksVI5DVG0bK+iJURyeo0SJlvhVDxWsZOnZ57asnEqcHIKHI7hFVz31Yx0dT5Yvx2n9M+FSV9H30jfDTxODUk39C2Ys+DQ/1Wr4xb4VZs8KnqpzyK+2NYHiNBogT71KFnWh616XDdOpx/K63gIlN/FpdiiiOwFgww5fspasyx+fsuoLRg4WHo964Nkzqd6sy5hSz7pS9o2b/2i+s4wLDcehM5QmUDtNovAC2NJEtwSNcN4EuEnhhARKbE7aK7UnU//Jk5UKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SXibD3dwhZtU8VXM3pFopcCZIopZpOmb+q0SJ2j4YUE=; b=mnWEbPN2cMV82kn9wyBSEm6giCL/OKXl7n8N/5BnodefQx9uoNRVotRE7KOnQRKbKZE89ZxgXHhCmJ5EY9081NJhOrnBnSzWZR6IiMkDvIJd7hSA7kjEqrXOfurd8OGkJEmJT3kKFbrVPIw+6665OK5cNZqvlhlOthG6B0RjfL+DPf7yEFdZLDU5yVOAZLQgB40xHO7TArhA3nIxQT2mSK0kFjIleE7on/MM/QLXDLb8h6Yfq4xiAM0IRTDO1Vs0iRdk2Nl5BZuADs3dMNwJ6dJEKHmy9jEcEFvHL7gLY0cmGQ9dzgiV2GBzZjqqLxnlRpPdSKqq5RdDEWJ8E7O6vQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) by LV9PR12MB9783.namprd12.prod.outlook.com (2603:10b6:408:2e8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9870.16; Mon, 27 Apr 2026 18:26:16 +0000 Received: from DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::f01d:73d2:2dda:c7b2]) by DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::f01d:73d2:2dda:c7b2%4]) with mapi id 15.20.9870.013; Mon, 27 Apr 2026 18:26:16 +0000 From: Zi Yan To: Usama Arif Cc: Andrew Morton , david@kernel.org, chrisl@kernel.org, kasong@tencent.com, ljs@kernel.org, bhe@redhat.com, willy@infradead.org, youngjun.park@lge.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, alex@ghiti.fr, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, npache@redhat.com, Liam.Howlett@oracle.com, ryan.roberts@arm.com, Vlastimil Babka , lance.yang@linux.dev, linux-kernel@vger.kernel.org, nphamcs@gmail.com, shikemeng@huaweicloud.com, kernel-team@meta.com, Ying Huang Subject: Re: [PATCH 00/13] mm: PMD-level swap entries for anonymous THPs Date: Mon, 27 Apr 2026 14:26:12 -0400 X-Mailer: MailMate (2.0r6290) Message-ID: In-Reply-To: <20260427100553.2754667-1-usama.arif@linux.dev> References: <20260427100553.2754667-1-usama.arif@linux.dev> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: MN2PR22CA0013.namprd22.prod.outlook.com (2603:10b6:208:238::18) To DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB9473:EE_|LV9PR12MB9783:EE_ X-MS-Office365-Filtering-Correlation-Id: 3ed2943a-7cbe-4bca-0808-08dea48a7817 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Mh16NtiPzU7i5T5j2NuuONZzWgdhGihTSyq5P59gtIFBb2zj2AvIgg7IcdG9hNUbVnWRTnF9bMR6HrFW9tdMiiEymOSpxgicvJgb/ZMEozeI9OWUb1CgmyV0yliG7lveLIeb8BHpi4KlYaBQz/E8X6ea+EklpdVLvYj8/KyCzIaqfTsSveoLECacVeZHtdyHrrwGdAPcSrluQ3RC/+c4tg/kvS5LFAJaaqimr3LuFJOMgVmg1Es4f/VNm0HiXVvEIHKQoyVUGyCAovRYYuAoK12GecKh4i7pEAXA+aRMMtouhOjjJH3GtoMgj9SaikEG8PsI6fUa/AY9cy36tNDlDjBCq8f9kw2yP4CofW3v5ARlTGF8JcYDTE5EkxyFSnuCEuRyhp5Nqw+/GBUCfewrG68l+FkfanYnaYhq3KI1r0CqxmmsWGLys40TQTlr+nQo0/d755uwa3exC/WOV951x4vBpgRRKG2lEpcW/VCNDXVMiuB0gUhn0vJf/GTXPInwPYeoBteg5YAjcCEsLr7ILhLTf44ijzRb1dB6myIex9RZwV+uXS1es52GjzrVVq5CIht3e9rYUgk3stkUXuvQGYvVag89TWdd4Uwu98mw2Np+S/QxIGUML/LhDTENGpEiLFRJQzAf57EKq1pTAeOMng+d5nn8gk1pLJ4jIDNh8qx2Ddx6YmGF6H9IJ3ij0oi2CCduo6Ja2Oe21U4cQ6PEisoWcxFYzRtJYdpQxWTbUpJXr9ntK+tPy0h6i/yMOlQ7 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB9473.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?rJYFYGD/oDtO7eHJonEm5oTjEdAdysjJ4m057WimWVaCoFq+3K3B03ijyR1D?= =?us-ascii?Q?G6gFSh96SZpZyQUQkVPPqTJmMfdmAsxIerHQ6FO87Bz0eqBvb/B2UG0G6yY8?= =?us-ascii?Q?Kf7oK2XkcqkO51f1D1j+CegwCzceQ8VveGXrLOcRyQBodGgu9kmwyQ5dEKGc?= =?us-ascii?Q?LocvVshoKIv+JiBA1o49aiUkPf7pDxgAGjuoTFMhD4XjhRzzRlXVU7HRGEof?= =?us-ascii?Q?slqzMHzSTeNLTtw/vt246Ryvrfuf1GchdUwmHg9ANFLFrRMyYz3vPb7SeSx6?= =?us-ascii?Q?qNfijjVSUhPzZSPNfttzqMAghCXof0FRibIZfsiZ9LLhiDkZKg8GpL/Q7qCR?= =?us-ascii?Q?OZZxV66fixIafEJxOvVdmQlW2IMl2xGEeo9fHbx9dhFCmRKo12YPyEK+8p03?= =?us-ascii?Q?ZULtGg3w6xuokxM+tows9/gNGzY3rImHPf+9OYbBc6hkVHG1IMYbYD3HgAqy?= =?us-ascii?Q?SaLZT2bp7W0zAsraVAzHHPJWruFsu/E+PDftF+Walskq74t0lYl3h18FLFeC?= =?us-ascii?Q?Lx89P1YksTsiDWDo8Yz47HJP3u3IlWtxcRIRIXMe0HUBK8X/M+5BIX1cxhYq?= =?us-ascii?Q?4NSr8HKHDbIg4t2A++8LrUnf42+FUmRJgsbgAKcscfaTId4O022LNc50wQQG?= =?us-ascii?Q?e4tS+KJQhF+1adhrmkGc8wsVSfEa3lSDSVk14ztwYhzWzPfzXEVyBhWLYQB0?= =?us-ascii?Q?+ZPZ/EstP6xujPqd1+9iLmScGL5zB5kZWdWfrYjS3fanpBFSXDlGGGL4XW6L?= =?us-ascii?Q?mllEKEPnn+X3etD5uz6JizbCp1uTlQ5FlQ6GCNWBLyX8rBGuNwrM7f0Z15zT?= =?us-ascii?Q?JBSgMhcfhKdNkKP8kleAAibBqvRxScqeNTJAuKpQ5v6Pk1o0O4xVnP6AQlA+?= =?us-ascii?Q?j5/MjxtMtIzLOLPNEHYh1jZfOntasToqR5Mdzzb+WqdfLyXxBj6xpCgVxLsk?= =?us-ascii?Q?5DV0OmzzzEmVFYH7fE+2XdHYLG+Fj3omce2Lx6xo/JtXZH+JQB6McMY44XTG?= =?us-ascii?Q?WF9UKCh/IPcG+aBXHiaEsaPbGM3kgiJcc3ctjyeDYslKWySpkYLmI3lBpud+?= =?us-ascii?Q?fj3lGlt3+wXhsu6S2PphvRXMsftUVAEASlSr1so3aV1why+eTXl5FjQ4llNu?= =?us-ascii?Q?Yd8bowaSnvdjn+asqn1+2XyqQhv1BhMQGp+6QoITqGiSFP+ySqyChQGXEEwz?= =?us-ascii?Q?EUhli+tB3TxxelORh4MVXkqeLyA/5Mb4JlT+lEkvycUbDlmTQREG7qOn0gqw?= =?us-ascii?Q?6iBArolKo5VLttgyUSVYjBhH3UjaqVDjKycfuiJ2IO8K+OZfk9GPvzwfTb0y?= =?us-ascii?Q?q/uhEDMu7ZBVy2pUK+ksnnLionsJXMFrqItFnzEAwvpW9GF3Gw5T34UcpRfB?= =?us-ascii?Q?ClJU8mq22aLq8RXGoA0t5aEwTdqg6uyVptc3u8jqJs5rGxhHJ9bg6lvAFgcs?= =?us-ascii?Q?6tmKcSM0KmgT//LbkdqBuFk3PIzF3UI2Xnj/3isbwvztjxQsL+Y9YKXSjWSZ?= =?us-ascii?Q?jxv0QFVaVVry25Yo/BQFmwcLRfgy7wBXeyYF+z86w4hc/x5+v7lt7pX6q/tF?= =?us-ascii?Q?Nalz5/RIV38PXGeXzRjJLoWf78o9nuDn8BvBZB8cWdNWWfMAqnzprbyo5VYT?= =?us-ascii?Q?eBi2tWnyXncpMELeJwDthG6iTMitSUXBm7/hRUusMN+dkbBIVWjwLfXVBmcR?= =?us-ascii?Q?OaaVFOGN4dynQfdMkRfePZgOFGQK3lvMToGXJ3Yt3wa3L1yv?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ed2943a-7cbe-4bca-0808-08dea48a7817 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB9473.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2026 18:26:16.2469 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zeZjnwkqvmVtDZo2W4AR8cZ0OvcX5NWpe/ujEIqe3PuVW5aCdiqbVKyD0/Q2WFLV X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9783 +Ying, who did the original THP swap work[1]. [1] https://lkml.org/lkml/2016/8/9/588 On 27 Apr 2026, at 6:01, Usama Arif wrote: > When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is > split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before > unmap. > > This series introduces a PMD-level swap entry. The huge mapping is > preserved across the swap round-trip, and do_huge_pmd_swap_page() > resolves the entire 2 MB region in a single fault on swap-in, > no khugepaged involvement is needed. swap_map metadata is identical > either way (512 single-slot counts), so the PTE split buys nothing > on the swap side, it is purely a page-table representation change. > > This work was brought about after Hugh reported that one of the > major blockers for having lazy page table deposit is the lack of > PMD swap entries [1]. However, this series has benefits of its > own: > - The huge mapping is restored on swap-in. Today even when the > folio is still in swap cache as a single 2 MB folio, the swap-in > path installs 512 PTE mappings -- the PMD mapping is gone, the > freshly-materialised PTE table sticks around, and only > khugepaged can later collapse the range back into a THP. > do_huge_pmd_swap_page() reinstalls the PMD mapping directly in > one fault, no khugepaged involvement. > - Memory saved per swapped-out THP *once lazy page table deposit is > merged* [2]. With lazy page table deposit [2], splitting a PMD into > 512 PTE swap entries forces allocation of a 4 KB PTE table page. > The new path leaves the pgtable hierarchy at PMD level and avoids > that allocation entirely. > This will save memory when swapping, which is likely when there is > memory pressure and exactly when allocations are most likely to > fail. > - Walkers (zap, mprotect, smaps, pagemap, soft-dirty, uffd-wp) > visit one PMD entry instead of 512 PTEs, reducing traversal > time and lock-hold windows. > > The swap entry value is identical to 512 PTE swap entries (same > type, same starting offset), so swap_map refcounting is unchanged. > Only the page-table representation differs; the swap slot allocator, > swap I/O, and swap cache are untouched. The new path falls back to > the existing PTE-split path whenever a PMD-order resource is > unavailable: zswap enabled, non-contiguous swap allocation > (THP_SWPOUT_FALLBACK), PMD-order folio allocation failure on swap-in > or fork, racing folio split, or rmap-driven split on a swapcache > folio. Walkers that previously assumed every non-present PMD encodes > a PFN (migration / device_private) are taught to recognise PMD swap > entries. > > Patch breakdown: > > The series is ordered to preserve git bisectability: every consumer > of a PMD swap entry (split, fork, swapoff, walkers, UFFDIO_MOVE, > swap-in fault) lands before the producer. The swap-out path that > actually installs PMD swap entries is the very last functional patch > (12), so no intermediate commit can leave the kernel handling a > PMD swap entry it does not yet understand. > > The first 4 patches are preparatory patches. Some of them (like > softleaf_to_pmd() change in patch 1) are not exactly needed but its > done to hopefully improve code quality and so that the PMD swap > entry changes look well integrated with the rest of mm. > > Prep patches: > 1. mm: add softleaf_to_pmd() and convert existing callers > PMD counterpart to softleaf_to_pte(); needed to construct a > PMD from a swap entry in later patches. > 2. mm: extract ensure_on_mmlist() helper > Hoists the "register mm with swapoff" double-checked-locking > pattern out of try_to_unmap_one() / copy_nonpresent_pte() so > the PMD swap-out and PMD fork paths can reuse it without a > third open-coded copy. > 3. fs/proc: use softleaf_has_pfn() in pagemap PMD walker > pagemap_pmd_range_thp() today calls softleaf_to_page() > unconditionally; a PMD swap entry has no PFN and would crash > it. > 4. mm/huge_memory: move softleaf_to_folio() inside migration branch > change_non_present_huge_pmd() today calls softleaf_to_folio() > before branching on entry type, so a PMD swap entry would > produce a bogus folio pointer that the migration-only code > below would then dereference. > > Core patches: > 5. PMD swap entry detection (pmd_is_swap_entry, > softleaf_is_valid_pmd_entry) and per-arch pmd_swp_*exclusive > helpers (x86/arm64/s390/riscv/loongarch). > 6. __split_huge_pmd_locked() learns to split a PMD swap entry > into 512 PTE swap entries, used as the fallback when a > PMD-order resource is unavailable. I was wondering how to handle insufficient memory during swap-in. Here it is. I have not read the code, but the split should be straightforward, since we already have a contiguous swap space at swap-out time and the split is just to enable PTE-level swap in, right? > 7. Fork: copy_huge_non_present_pmd() duplicates the PMD swap entry > in one folio_dup_swap() call, with GFP_KERNEL retry mirroring > copy_pte_range(). > 8. Swapoff: unuse_pmd() reads the whole 2 MB folio and reinstalls > the PMD; falls back to PTE-split + unuse_pte_range() on error. > 9. Walker updates: zap_huge_pmd, change_huge_pmd, > change_non_present_huge_pmd, move_soft_dirty_pmd, > clear_soft_dirty_pmd, make_uffd_wp_pmd, smaps_pmd_entry, > queue_folios_pmd (mempolicy), check_pmd_state (khugepaged), > and the madvise_cold_or_pageout_pte_range / madvise_free_huge_pmd > VM_BUG_ON extensions. > 10. UFFDIO_MOVE: move_pages_huge_pmd() learns to move a PMD swap > entry whole via a new move_swap_pmd() helper modeled on > move_swap_pte(). > 11. Swap-in: do_huge_pmd_swap_page() resolves a PMD swap fault in > one shot. Handles racing splits, SWP_STABLE_WRITES read-only > mapping, immediate COW for write faults; falls back to PTE-split > on any PMD-order resource shortfall. > 12. Swap-out: shrink_folio_list() drops TTU_SPLIT_HUGE_PMD for > PMD-mappable swapcache folios (when zswap is disabled), and > try_to_unmap_one() installs one PMD swap entry via > set_pmd_swap_entry() instead of splitting. > > Testing: > 13. selftests/mm: 12 tests covering swap-out/in, fork, fork+COW, > repeated cycles, write fault, munmap, mprotect, mremap, pagemap, > MADV_FREE, UFFDIO_MOVE, swapoff. > > Making PMD swap entries work with zswap is another project on its own a= nd > should be in a separate follow up series. > > The patches are on top of mm-unstable from 23 April > (2bcc13c29c711381d815c1ba5d5b25737400c71a). > > [1] https://lore.kernel.org/all/6869b7f0-84e1-fb93-03f1-9442cdfe476b@go= ogle.com/ > [2] https://lore.kernel.org/all/20260327021403.214713-1-usama.arif@linu= x.dev/ > > Usama Arif (13): > mm: add softleaf_to_pmd() and convert existing callers > mm: extract ensure_on_mmlist() helper > fs/proc: use softleaf_has_pfn() in pagemap PMD walker > mm/huge_memory: move softleaf_to_folio() inside migration branch > mm: add PMD swap entry detection support > mm: add PMD swap entry splitting support > mm: handle PMD swap entries in fork path > mm: swap in PMD swap entries as whole THPs during swapoff > mm: handle PMD swap entries in non-present PMD walkers > mm: handle PMD swap entries in UFFDIO_MOVE > mm: handle PMD swap entry faults on swap-in > mm: install PMD swap entries on swap-out > selftests/mm: add PMD swap entry tests > > arch/arm64/include/asm/pgtable.h | 4 + > arch/loongarch/include/asm/pgtable.h | 17 + > arch/riscv/include/asm/pgtable.h | 15 + > arch/s390/include/asm/pgtable.h | 15 + > arch/x86/include/asm/pgtable.h | 15 + > fs/proc/task_mmu.c | 47 +- > include/linux/huge_mm.h | 11 + > include/linux/leafops.h | 44 +- > include/linux/swap.h | 4 +- > include/linux/vm_event_item.h | 1 + > mm/hmm.c | 3 +- > mm/huge_memory.c | 540 +++++++++++++++++++++-- > mm/internal.h | 49 +++ > mm/khugepaged.c | 6 + > mm/madvise.c | 5 +- > mm/memory.c | 51 +-- > mm/mempolicy.c | 2 + > mm/rmap.c | 27 +- > mm/swap.h | 7 + > mm/swap_state.c | 35 ++ > mm/swapfile.c | 144 +++++- > mm/vmscan.c | 14 +- > mm/vmstat.c | 1 + > tools/testing/selftests/mm/Makefile | 1 + > tools/testing/selftests/mm/pmd_swap.c | 607 ++++++++++++++++++++++++++= > 25 files changed, 1554 insertions(+), 111 deletions(-) > create mode 100644 tools/testing/selftests/mm/pmd_swap.c > > -- = > 2.52.0 Best Regards, Yan, Zi