From mboxrd@z Thu Jan 1 00:00:00 1970 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 21027C54E58 for ; Fri, 22 Mar 2024 02:51:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 95CCD6B0088; Thu, 21 Mar 2024 22:51:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90CF56B0089; Thu, 21 Mar 2024 22:51:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7860C6B008C; Thu, 21 Mar 2024 22:51:19 -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 68B2F6B0088 for ; Thu, 21 Mar 2024 22:51:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F2A7016061E for ; Fri, 22 Mar 2024 02:51:16 +0000 (UTC) X-FDA: 81923148552.15.0BE1539 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 2FA7540005 for ; Fri, 22 Mar 2024 02:51:14 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aQHe1bwy; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711075874; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ui8J3jwhgVwUBohP86gKySPzBpYeTdjDebBsw2pygnU=; b=5uoHuxrP9QCGHJbwtut30ZIXXm5b3hAn5sm666rJQZDC8Ab33+uQfZlsEs+7eKLFz3iV1g eJWcYTGZL5UBY0kRhq6P651BUorx5U+j3cmTveFcLaZLoDGOGF187lfPVHQz4sh8uM2+lI 2eKWh7exHvVCLIVTk9KmNYBbI4sk+sg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711075874; a=rsa-sha256; cv=none; b=D1iHUYMY4IHS0rNSOzPHuzuH9Fob7TZw0JzIyAouuSFtlF8dLQgLR0Yue0JIL6IZKRVtd7 vtcLnGd5c/DeI7dc0EL36XHTZtMtG3MDFF/qJx8WrNFBW+cVLKCaKvfoWDQSWGa/+jbAx/ 7jVAJLNlMD7svQOESLVdvsMPu6TSGtw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aQHe1bwy; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-4765e6cf37aso564540137.1 for ; Thu, 21 Mar 2024 19:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711075873; x=1711680673; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ui8J3jwhgVwUBohP86gKySPzBpYeTdjDebBsw2pygnU=; b=aQHe1bwyE4TZwzf83SVgEKNH01/e63DnZ434QT/gczI5ACmoStW5FBabVR0fHjE83X PsETswJJLTVmfJKib6JU2gjyrxVYl1TmbNU3Z6H/4Ysr11spaOanBm7X939lQT4CdS6B 0af3og2b7nwEe6IGaj3CPE6vSUBg7pnmFlzmyyjNbZIfY35gEjuq+94vAoPHxRcqueCR V70+oEYUSqXprZAsPiKHwECLJVilR4dEJt2+bz6AeYWpE6PoJH4NeW+MKhP1wEUNcFa/ A4K1dR9OWaCFM8zA60ZGcJ5zzbR9N84Gz3UVBb4xLk9kFqDx9sMZVpuXK0a7x1Y/5jj1 pfCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711075873; x=1711680673; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ui8J3jwhgVwUBohP86gKySPzBpYeTdjDebBsw2pygnU=; b=W/iBumA6cPsdljvEyGk+3s9aeHvQCM7LOoxJFDcraMH55troUam0RT736bbhPytHZQ j+VE7nKI5dZ7adCQhmrg4FfZwL+bzxjg3OOseZe2qyqirXiBq2uMJo32X4FEPnsqAMHq fswC7rwXYb7DmG6meRvZ7nWAaeqgNs0zpe5vqiBVpcUaebPwyOKw1rqUxiopo3dOZTz8 pKkT8dejfTIN8hYHkbNkrDAHiP/CX6y2gpLaG+f9sepMPGUdj1fjJuFBmzHpJU34GfgC EgEbEeAuAwWKINFtATaW7h0SERJZ9JRs58ZBwmURGhXDumCLBCek/IX+oqBvAY14eMEY zbRg== X-Forwarded-Encrypted: i=1; AJvYcCVqd3i+pamuvI1ONrpK5dKpe8Vwq4gnzeRdNMDZTDR3gN6KVPohh3YWX+CQjOmx+NKYoT07N1RAeMt7NS6uQF+MoaM= X-Gm-Message-State: AOJu0YwM1FPsTHYTYaA+5sc7wrPTFmwTLE6P/CYuBg3tEI3yRYEJsChl 3mTq06WtyC9pC7GziAMnoVJ/Tr48OG2X7y0VaCtOvcbAmMPOg/OXsp3G+NzzjF64L2Fw+jZFZ6t cVSnS67lIK5dt0x4u57KCc2weRp0= X-Google-Smtp-Source: AGHT+IFi/1kYX4l7+af7iw8yrHFkHMv2ZIllbxh/oEZC5uOR5nawGOpvijb3SK7ppUH+sDFCimlQ9V4AWJz0GtWHemQ= X-Received: by 2002:a67:fd11:0:b0:475:fe59:f33 with SMTP id f17-20020a67fd11000000b00475fe590f33mr1252338vsr.29.1711075873175; Thu, 21 Mar 2024 19:51:13 -0700 (PDT) MIME-Version: 1.0 References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-2-21cnbao@gmail.com> <01c61b90-df90-4819-978b-414bb717ef64@arm.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 22 Mar 2024 15:51:01 +1300 Message-ID: Subject: Re: [RFC PATCH v3 1/5] arm64: mm: swap: support THP_SWAP on hardware with MTE To: Ryan Roberts Cc: akpm@linux-foundation.org, linux-mm@kvack.org, chengming.zhou@linux.dev, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mhocko@suse.com, nphamcs@gmail.com, shy828301@gmail.com, steven.price@arm.com, surenb@google.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, Barry Song , Catalin Marinas , Will Deacon , Mark Rutland , Kemeng Shi , Anshuman Khandual , Peter Collingbourne , Peter Xu , Lorenzo Stoakes , "Mike Rapoport (IBM)" , Hugh Dickins , "Aneesh Kumar K.V" , Rick Edgecombe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2FA7540005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: zh3a4q3d1wnjkkg3chmxdpta5i47un7u X-HE-Tag: 1711075874-891403 X-HE-Meta: U2FsdGVkX1/XMylo2qTLvopgZpQekce/yxcuo1QnXpuSXgNFw+5l5r381C8pUzXeLaXPCXvFzVFtcN55Wzwt55FjLXSN157NjFhrC9hkTU0vrPNjyo1gqFYSIGpj4eRTAio8mUrSizj6qExSA1B+69jhLT6YGNKCOu/EsTlop/EE7DumbVc24puvTtRMti9U4uT5h1sJ/V7LYP+3pqlqTQs7tbUhzJyRc5P7FWOMZDDeS3aI+6JMkQv/vPR5Ve11VHXc+2MclvNxM3+/zMkHYgkXQUap3duGYJvXpbTdQq69GbB1wZvMECajKYFXABGh7LWjNs/i/gbX7W3X9ot8afZE82Bjdgvjw6rUndpchCvNLUvXsjeIPL27z1MElYUO2WzDpR4Cg0yesgJF/l6FVg0fg2sqZjOdOoUfIdV6Ar0g9jRzllyyDCqapaKuMxX5mq5i63UTdm2sDqimWTQuYClbR5U2DTRVFuMq8NaROetmlOVlKfiwD3ZaSBYXeEwCyWtwq0fwHoRWkDCj3u7EetIJDp9WXd0dXlXXBuv04UDVes/Jr7xyIPK+KminTwMVjfvxUP4C8HgS+Iky2W5pa+NMQ/IeSH0jLoSvwH1F5oOtlcIlIuQhraHTqLeesvPysrHGeNhmIKFUaJzkM20nl85bcqESJMxUWMrJsYsn3fwNagG/9JbeIlC7e2e+I5QQNwAWs7Y9kxpzu1NoiZnIl78PZDm40LWCnWABzPgr7i96eYLBeji/hVnZulFDod88S2tV228ZUJjYbDzBS9Q3IJ/MzFjaS9wEzG6/DXhFL0kc6iXGSIbd42Y09uXJvoEeY1T35dQks8QlDyx/xyTV91j9H8foeJ88anrsyPN6sU8KF4q/PHa2wTMKfmXfSpLfLxPz78O5cUFPhdNttXty/GcLnMAYIAOJv2Tf+d8q/h6qeoyC0txKi8lnwxGv0m2cHKnZ8kIboxbcX8qHdnj UyCy/HBb C+EZaGvqvptivyJcgywNu8wKiFzHh2gCObkFTmLI454j9Ozkn91KJW5zeWOi/tmLTyem7wND2vBC8Itmp+cL/LQXT7EYbUMfrfInKmEXElzKD4W/URfIghIah0jIZixReyajhamibRtspZ4AiLxOJDQibtqpzW1kxx0VEi/GxlQQB0s+W5xQJQgUryNZHJmtcJhVowHNrZGpoEcfG1RJZKOI2ldVF9EQ9NhT/6vo2ATnI7YOVh7m/XzFzlwHIdy+20u9XIPxcHcjeqf8fQoR3IcbkOHKy5/PS/NHEmBLrvjJstSGMXR5yAJul2jwl6xyxzysHUrxLn06ZkK2cEbkziEF8UeeqSfmI6GL10WyHqr2Z+Uk8n65tP9Vd/+AimDYaLL3QdvreuLyTC+yGmzbU2bY5VjgjIM8rsghDntNfkae9kD6aIlZtUU9Y0dpxSIozj18lOD9/L1NLRYvgbeLr9xoXt9OqYezaMcZmNgCmYjOfE63loclb8hI65/6T6BTBYakxsUyRScWjJXHTc9Yc57POZsJMz/w86SNf7yixZyr7aeqUXJYc4EUIsbD8qOo2a7LOp9BzJiezMDlxOwPNUi2NiDq9+rhPcQXru/2xOUCFRaxMDQNT7NluoYYJguwjrcBdZ1j/jcTlr26ggsz1XA8XRPUWcl9h4GGF1NhkyA+JIpN5R8EEjW4KJI7wm7Xgpt5Dvof91UHA5V2rsGGhY7ZIuJ1Yobvysv7hp31UTBGOuZRR+ZuWp5vSXFj8AfioGv2fLyeL0AGjmQpjGArkt8LOCUP6g3nTgZQ+9tHs4dznAI5CV32Jbn7shQ== 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: On Thu, Mar 21, 2024 at 11:31=E2=80=AFPM Ryan Roberts wrote: > > On 21/03/2024 08:42, Barry Song wrote: > > Hi Ryan, > > Sorry for the late reply. > > No problem! > > > > > On Tue, Mar 12, 2024 at 5:56=E2=80=AFAM Ryan Roberts wrote: > >> > >> On 04/03/2024 08:13, Barry Song wrote: > >>> From: Barry Song > >>> > >>> Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up > >>> THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with > >>> MTE as the MTE code works with the assumption tags save/restore is > >>> always handling a folio with only one page. > >>> > >>> The limitation should be removed as more and more ARM64 SoCs have > >>> this feature. Co-existence of MTE and THP_SWAP becomes more and > >>> more important. > >>> > >>> This patch makes MTE tags saving support large folios, then we don't > >>> need to split large folios into base pages for swapping out on ARM64 > >>> SoCs with MTE any more. > >>> > >>> arch_prepare_to_swap() should take folio rather than page as paramete= r > >>> because we support THP swap-out as a whole. It saves tags for all > >>> pages in a large folio. > >>> > >>> As now we are restoring tags based-on folio, in arch_swap_restore(), > >>> we may increase some extra loops and early-exitings while refaulting > >>> a large folio which is still in swapcache in do_swap_page(). In case > >>> a large folio has nr pages, do_swap_page() will only set the PTE of > >>> the particular page which is causing the page fault. > >>> Thus do_swap_page() runs nr times, and each time, arch_swap_restore() > >>> will loop nr times for those subpages in the folio. So right now the > >>> algorithmic complexity becomes O(nr^2). > >>> > >>> Once we support mapping large folios in do_swap_page(), extra loops > >>> and early-exitings will decrease while not being completely removed > >>> as a large folio might get partially tagged in corner cases such as, > >>> 1. a large folio in swapcache can be partially unmapped, thus, MTE > >>> tags for the unmapped pages will be invalidated; > >>> 2. users might use mprotect() to set MTEs on a part of a large folio. > >>> > >>> arch_thp_swp_supported() is dropped since ARM64 MTE was the only one > >>> who needed it. > > I think we should decouple this patch from your swap-in series. I suspect= this > one could be ready and go in sooner than the swap-in series based on the = current > discussions :) > > >>> > >>> Cc: Catalin Marinas > >>> Cc: Will Deacon > >>> Cc: Ryan Roberts > >>> Cc: Mark Rutland > >>> Cc: David Hildenbrand > >>> Cc: Kemeng Shi > >>> Cc: "Matthew Wilcox (Oracle)" > >>> Cc: Anshuman Khandual > >>> Cc: Peter Collingbourne > >>> Cc: Steven Price > >>> Cc: Yosry Ahmed > >>> Cc: Peter Xu > >>> Cc: Lorenzo Stoakes > >>> Cc: "Mike Rapoport (IBM)" > >>> Cc: Hugh Dickins > >>> CC: "Aneesh Kumar K.V" > >>> Cc: Rick Edgecombe > >>> Signed-off-by: Barry Song > >>> Reviewed-by: Steven Price > >>> Acked-by: Chris Li > >>> --- > >>> arch/arm64/include/asm/pgtable.h | 19 ++------------ > >>> arch/arm64/mm/mteswap.c | 43 ++++++++++++++++++++++++++++++= ++ > >>> include/linux/huge_mm.h | 12 --------- > >>> include/linux/pgtable.h | 2 +- > >>> mm/page_io.c | 2 +- > >>> mm/swap_slots.c | 2 +- > >>> 6 files changed, 48 insertions(+), 32 deletions(-) > >>> > >>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/as= m/pgtable.h > >>> index 401087e8a43d..7a54750770b8 100644 > >>> --- a/arch/arm64/include/asm/pgtable.h > >>> +++ b/arch/arm64/include/asm/pgtable.h > >>> @@ -45,12 +45,6 @@ > >>> __flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1) > >>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > >>> > >>> -static inline bool arch_thp_swp_supported(void) > >>> -{ > >>> - return !system_supports_mte(); > >>> -} > >>> -#define arch_thp_swp_supported arch_thp_swp_supported > >>> - > >>> /* > >>> * Outside of a few very special situations (e.g. hibernation), we a= lways > >>> * use broadcast TLB invalidation instructions, therefore a spurious= page > >>> @@ -1095,12 +1089,7 @@ static inline pmd_t pmdp_establish(struct vm_a= rea_struct *vma, > >>> #ifdef CONFIG_ARM64_MTE > >>> > >>> #define __HAVE_ARCH_PREPARE_TO_SWAP > >>> -static inline int arch_prepare_to_swap(struct page *page) > >>> -{ > >>> - if (system_supports_mte()) > >>> - return mte_save_tags(page); > >>> - return 0; > >>> -} > >>> +extern int arch_prepare_to_swap(struct folio *folio); > >>> > >>> #define __HAVE_ARCH_SWAP_INVALIDATE > >>> static inline void arch_swap_invalidate_page(int type, pgoff_t offse= t) > >>> @@ -1116,11 +1105,7 @@ static inline void arch_swap_invalidate_area(i= nt type) > >>> } > >>> > >>> #define __HAVE_ARCH_SWAP_RESTORE > >>> -static inline void arch_swap_restore(swp_entry_t entry, struct folio= *folio) > >>> -{ > >>> - if (system_supports_mte()) > >>> - mte_restore_tags(entry, &folio->page); > >>> -} > >>> +extern void arch_swap_restore(swp_entry_t entry, struct folio *folio= ); > >>> > >>> #endif /* CONFIG_ARM64_MTE */ > >>> > >>> diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c > >>> index a31833e3ddc5..295836fef620 100644 > >>> --- a/arch/arm64/mm/mteswap.c > >>> +++ b/arch/arm64/mm/mteswap.c > >>> @@ -68,6 +68,13 @@ void mte_invalidate_tags(int type, pgoff_t offset) > >>> mte_free_tag_storage(tags); > >>> } > >>> > >>> +static inline void __mte_invalidate_tags(struct page *page) > >>> +{ > >>> + swp_entry_t entry =3D page_swap_entry(page); > >>> + > >>> + mte_invalidate_tags(swp_type(entry), swp_offset(entry)); > >>> +} > >>> + > >>> void mte_invalidate_tags_area(int type) > >>> { > >>> swp_entry_t entry =3D swp_entry(type, 0); > >>> @@ -83,3 +90,39 @@ void mte_invalidate_tags_area(int type) > >>> } > >>> xa_unlock(&mte_pages); > >>> } > >>> + > >>> +int arch_prepare_to_swap(struct folio *folio) > >>> +{ > >>> + long i, nr; > >>> + int err; > >>> + > >>> + if (!system_supports_mte()) > >>> + return 0; > >>> + > >>> + nr =3D folio_nr_pages(folio); > >>> + > >>> + for (i =3D 0; i < nr; i++) { > >>> + err =3D mte_save_tags(folio_page(folio, i)); > >>> + if (err) > >>> + goto out; > >>> + } > >>> + return 0; > >>> + > >>> +out: > >>> + while (i--) > >>> + __mte_invalidate_tags(folio_page(folio, i)); > >>> + return err; > >>> +} > >>> + > >>> +void arch_swap_restore(swp_entry_t entry, struct folio *folio) > >> > >> I'm still not a fan of the fact that entry could be anywhere within fo= lio. > >> > >>> +{ > >>> + if (system_supports_mte()) { > >> > >> nit: if you do: > >> > >> if (!system_supports_mte()) > >> return; > > > > Acked > > > >> > >> It will be consistent with arch_prepare_to_swap() and reduce the inden= tation of > >> the main body. > >> > >>> + long i, nr =3D folio_nr_pages(folio); > >>> + > >>> + entry.val -=3D swp_offset(entry) & (nr - 1); > >> > >> This assumes that folios are always stored in swap with natural alignm= ent. Is > >> that definitely a safe assumption? My swap-out series is currently ens= uring that > >> folios are swapped-out naturally aligned, but that is an implementatio= n detail. > >> > > > > I concur that this is an implementation detail. However, we should be > > bold enough > > to state that swap slots will be contiguous, considering we are > > currently utilizing > > folio->swap instead of subpage->swap ? > > Yes, I agree about contiguity. My objection is about assuming natural ali= gnment > though. It can still be contiguous while not naturally aligned in swap. Hi Ryan, While working on the new version of this patch, I've come to recognize that, for the time being, it's imperative to maintain a natural alignment. The following code operates on the basis of this assumption. /** * folio_file_page - The page for a particular index. * @folio: The folio which contains this index. * @index: The index we want to look up. * * Sometimes after looking up a folio in the page cache, we need to * obtain the specific page for an index (eg a page fault). * * Return: The page containing the file data for this index. */ static inline struct page *folio_file_page(struct folio *folio, pgoff_t ind= ex) { return folio_page(folio, index & (folio_nr_pages(folio) - 1)); } It's invoked everywhere, particularly within do_swap_page(). Nonetheless, I remain confident that I can consistently pass the first entry to arch_swap_restore(). > > > > >> Your cover note for swap-in says that you could technically swap in a = large > >> folio without it having been swapped-out large. If you chose to do tha= t in > >> future, this would break, right? I don't think it's good to couple the= swap > > > > Right. technically I agree. Given that we still have many tasks involvi= ng even > > swapping in contiguous swap slots, it's unlikely that swapping in large= folios > > for non-contiguous entries will occur in the foreseeable future :-) > > > >> storage layout to the folio order that you want to swap into. Perhaps = that's an > >> argument for passing each *page* to this function with its exact, corr= esponding > >> swap entry? > > > > I recall Matthew Wilcox strongly objected to using "page" as the > > parameter, so I've > > discarded that approach. Alternatively, it appears I can consistently p= ass > > folio->swap to this function and ensure the function always retrieves > > the first entry? > > Yes, if we must pass a folio here, I'd prefer that entry always correspon= ds to > the first entry for the folio. That will remove the need for this functio= n to do > the alignment above too. So win-win. > > > > >> > >>> + for (i =3D 0; i < nr; i++) { > >>> + mte_restore_tags(entry, folio_page(folio, i)); > >>> + entry.val++; > >>> + } > >>> + } > >>> +} > >>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > >>> index de0c89105076..e04b93c43965 100644 > >>> --- a/include/linux/huge_mm.h > >>> +++ b/include/linux/huge_mm.h > >>> @@ -535,16 +535,4 @@ static inline int split_folio_to_order(struct fo= lio *folio, int new_order) > >>> #define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l,= 0) > >>> #define split_folio(f) split_folio_to_order(f, 0) > >>> > >>> -/* > >>> - * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP d= ue to > >>> - * limitations in the implementation like arm64 MTE can override thi= s to > >>> - * false > >>> - */ > >>> -#ifndef arch_thp_swp_supported > >>> -static inline bool arch_thp_swp_supported(void) > >>> -{ > >>> - return true; > >>> -} > >>> -#endif > >>> - > >>> #endif /* _LINUX_HUGE_MM_H */ > >>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > >>> index e1b22903f709..bfcfe3386934 100644 > >>> --- a/include/linux/pgtable.h > >>> +++ b/include/linux/pgtable.h > >>> @@ -1106,7 +1106,7 @@ static inline int arch_unmap_one(struct mm_stru= ct *mm, > >>> * prototypes must be defined in the arch-specific asm/pgtable.h fil= e. > >>> */ > >>> #ifndef __HAVE_ARCH_PREPARE_TO_SWAP > >>> -static inline int arch_prepare_to_swap(struct page *page) > >>> +static inline int arch_prepare_to_swap(struct folio *folio) > >>> { > >>> return 0; > >>> } > >>> diff --git a/mm/page_io.c b/mm/page_io.c > >>> index ae2b49055e43..a9a7c236aecc 100644 > >>> --- a/mm/page_io.c > >>> +++ b/mm/page_io.c > >>> @@ -189,7 +189,7 @@ int swap_writepage(struct page *page, struct writ= eback_control *wbc) > >>> * Arch code may have to preserve more data than just the page > >>> * contents, e.g. memory tags. > >>> */ > >>> - ret =3D arch_prepare_to_swap(&folio->page); > >>> + ret =3D arch_prepare_to_swap(folio); > >>> if (ret) { > >>> folio_mark_dirty(folio); > >>> folio_unlock(folio); > >>> diff --git a/mm/swap_slots.c b/mm/swap_slots.c > >>> index 90973ce7881d..53abeaf1371d 100644 > >>> --- a/mm/swap_slots.c > >>> +++ b/mm/swap_slots.c > >>> @@ -310,7 +310,7 @@ swp_entry_t folio_alloc_swap(struct folio *folio) > >>> entry.val =3D 0; > >>> > >>> if (folio_test_large(folio)) { > >>> - if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_support= ed()) > >>> + if (IS_ENABLED(CONFIG_THP_SWAP)) > >>> get_swap_pages(1, &entry, folio_nr_pages(folio)= ); > >>> goto out; > >>> } > >> > > > > Thanks > > Barry >