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 69EF5C54E68 for ; Thu, 21 Mar 2024 10:44:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF7CC6B0083; Thu, 21 Mar 2024 06:44:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C80D66B0085; Thu, 21 Mar 2024 06:44:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFBFF6B0087; Thu, 21 Mar 2024 06:44:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 98CF36B0083 for ; Thu, 21 Mar 2024 06:44:12 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 62F2D1A1019 for ; Thu, 21 Mar 2024 10:44:12 +0000 (UTC) X-FDA: 81920711544.19.617A8CE Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf29.hostedemail.com (Postfix) with ESMTP id 959CE120007 for ; Thu, 21 Mar 2024 10:44:10 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VPXGECTP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711017850; 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=iGNKVqLixwBJC1Vd2ymCbdiOgs9xUopOw3+FI5+W+fY=; b=aygui9DicUssJMt5iN3APzHjCHOwjwcI+qDV3URFLg5Q7O2oTGEa3jmjqZrzJiScn4HvYH kxTR0Dzdu40EGD09SX+xATMEpxFBtcRPtMxFxhyJXXeNwNgrsvJ7aDP8hez8Ao3InL5Tc9 Zo9KY7SZoe5DdsKfsgvBMwo0cq6084s= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VPXGECTP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711017850; a=rsa-sha256; cv=none; b=59BFoSM/98oeLXBhJFpCJa1EDQBlwNMm1FWk4wPwA/TFv+6e7APssZTsCoXXtX2+FtU+hc SntMGDgcrSwNyqI2I4m4GpBu6LeuJLa6F2T7ZIp5X4x579gdoJhpoXLR+7lJiynjlGiX4X Q88OO+vmSp9o+okc8WA8rnoNS/SDZ3I= Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-7e05d6871ddso374395241.1 for ; Thu, 21 Mar 2024 03:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711017850; x=1711622650; 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=iGNKVqLixwBJC1Vd2ymCbdiOgs9xUopOw3+FI5+W+fY=; b=VPXGECTPa78z0u2IKIB/bFdlCdeLilOqK94B9rLwTuVzudCgtEUl2J874vulaHAe70 L+lvF2AM0WnJ5SDl8FaWIkPpZe1T4vMytNd9YdIStq2+73JAc6ImVUzYYy9MFZp7WFHd ORv6DT8ygr6r3utUD4oSi+FYGl2vdQGRQkzgN97RxRLOJTY4Pa4BdsegTDm3VkQqh//O TyzWbn9DUv8M6MuWbp8tGSHHUHAfFXSkFUCw89q+oQDw3exRhvLeuQqKdKGqcnYl2cW8 Lm6ooJTjr2Jx9xoSd5B8IGF3fMi/Tj0/fUf3nISEwmZP14Q9Hulp8FR3JV5pIbb/EI6n NcYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711017850; x=1711622650; 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=iGNKVqLixwBJC1Vd2ymCbdiOgs9xUopOw3+FI5+W+fY=; b=O3B52AjKLVQrXz85bd8eRIFR2owva9yb2gcSRq+HB3kfMUMbtoYSr1zMqjgqg/Ggjz DStzSaY/qf809g7Zy+qRlH7MGG2Wf1TWc4DoCiV5u6qUCVQQgzO5zT4CH3xaCikbd2YF KBJtqr01ZcPOps/VABHrKQeW9mmegNyLtVUMMyMUluoCQ4gsEbfFCYwvLu2dTBRBNpzA jksLhOJOVf15Hs6xVWKC5etXkg+ecwwjOX7MenMk2/eyGH8oom0AOwMo2nHQTxoKL5Zi QbRqGUXn+SUja9j0bcNTpRDr5YOP47wKet/fbZ6xzab7+aYd/W0Bo3JOCG+KskR+m+R+ j8mA== X-Forwarded-Encrypted: i=1; AJvYcCXdQJkv/tkdEbGhi2+HFHXdRN1wJ7GGQruSJdLi7/qx+AGxrmnPYd/oOLDcP3ia0g3iXXRNBYgrdI6SssWXS7dmUaU= X-Gm-Message-State: AOJu0YySqrPk/oA2YSIWbDkHq+6R7juPmH6hhx/jMtmkO3/GK79aZwHA kSGEw702DhQMCQ+PU74eI49XRSTTBQZ9T9xHF4xSqsEbYzuWl5zrKtQpAugGdLdjaekWuj9S5LJ Kk/EaQIgCt/QxhkN+AnBqAJTGvKI= X-Google-Smtp-Source: AGHT+IFVpTUtS3RKZd4uee1A7DQWV+55ipcZhVGdwto8Kr/uMq+dECfpnlszzEy/+uiOfZV2g1RrBJYBbBylLfJF/AE= X-Received: by 2002:a67:f70b:0:b0:473:2d3c:b96a with SMTP id m11-20020a67f70b000000b004732d3cb96amr1351666vso.19.1711017849243; Thu, 21 Mar 2024 03:44:09 -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: Thu, 21 Mar 2024 18:43:58 +0800 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-Server: rspam09 X-Rspamd-Queue-Id: 959CE120007 X-Stat-Signature: 7739ja8x8egw9qj4ocmo47h8pr8ma68c X-Rspam-User: X-HE-Tag: 1711017850-331827 X-HE-Meta: U2FsdGVkX197WXr6Zfcc9u4Q+dfb1cg0052K5ZKDAF2fxv52xq5ffWSuulZtnJQ/VEKnmpdizgQUHuXWfNwFa/Jl1xnc5IZXxWJm2jmMns5vxOPNGBppXTFTWkqLd03J8yY6Pae3uqUgQnBbuY01nBM/yMDXos+AVxxpzreATonycoc/9aw51QHSKdf1XLqqu933gz0X95qAs49iUcmdaqOkDJscgqvZHBnUKIczwxKV/mgFSmVoq3L+L9UH8qBqg1vj2ZzHfxTfXyG3XAm5zQRu1v7Mghaei4zK4QXUeTmIgcWwE+nl05eWMrRys86zEn+vlyzdBVo2frmt5BR/YClD/hvypSgmXs0jlLtARtY/JSiYgP9jdCOqApY8qBq42Fvkf4TooeJksEQU8QNPi2V7oqZ814QCwIreXqg7Sfk12mzH61xanaKoBnhmtj7v/ChjO1N6IUASs7amhOaDPqaRRoEowk7UfVbpCtk9JWAe58QBljzNjyg4/Ar7uQm1linS6c3rpaRB4mIr4iz6FLlgPcL7VvNT5QARzDRfWsMV7c183y35quL9UrM6CeEBlr3eh30aIm4sj/X2h2jseTWZo3r/mk10NPR+/yyQNHoZj2vmICFxKgVbqzg0zuDBnXoOiGYwTDIfdiwIiO5Q9TJmke9IvXdL4hSOZuxXwdEGy/pDddq1Q7WzohEDWabzpey8V4wHDKnyqKXJK4RP4W5ECWOE6db8NZkGDtBEvdvomABUCbjDYl+YDn1v4it4uBdCpHw2A5XRr/pNg6DMd3Q+BbXNebAePBvftomVzTZ9/Z0eRtGI2RPN3RLZWxghFyOQJSPEsYisPyu0xb/qVKa/xK4rfHMYEQXEq9JGIXSMyC56DW5EdzpaTerSLmhUDYQ2+5z0u6nih+BtXk9Xyw/183xN/glWz8W5yoIe1Wm92EKA4va9+ldvNTvAMROaOoOwsHbDcPfR3TZooyK aeD1SH6k XsoBTJqXQabao3FuTB38nDwz4G7+e7NduObPiU0sl/mv+QlKwIlF2UDW6eTqW4cCFv8Vc2jE5Qh2uz84tHJ0p31C3FqDksFpzfszK44FxVgk71pogyf2CKENB3B1Q7UJF77bAJ0Zgjg0+7VYkfAcaiN3yyajhzlXlhHed6+xttWfaI13XWy8/49u9KNLrrtwCzxyrbKHL1kWbxV4nQUzrL36Nw1tnvFwKRRKLPN3mW/hYISw2JVZMeCHH/otgyoDT1CBO9NNaziI017yw9ssWSZHrBxJG8ZXBdmWYLtfG3PhEJzackXxsokSegD2Lw6cgeyZsm7k4D57NBpdvuUFnU45kwHBJStAIbd6KSkb0rQQ8Z7tEdCw4NXp/+mUCDaEhMznv8rlIGNUDdrbUFsiqWRcLH7PrK3m0PJayXLdmCpR5DPghaX+uJIqqml9ACS10npq07AOUn6XZYXMUGz/fwyiCUSK3Woa4EQBM44u2tPNu3HDAsjTrmAbLb37b2s2Ob7rmmwmjiQ7ROxy5JRaz8tsnFPrT2dRytTTk/+zSRokNXVRaKfknbQJ63Hzj7NCta/TAUgPMSWRFhzlUmLszGctQ1jFRjAmITOMt92cSXfoYlkECwfVXXpJgHKpQBl5Kkg62EsUIEtCgD6PYoysDczUYNuo+/n0OhGbVLQXfyhq7UL9noeywRSee6pGqEI9TmW2EXm67CoDoBm08tjWnRMaYvwqIepmk0do6D4JiW/BEClQgu50FrveWc28WrjuQctGxq96bb5pSBlfKiDSenDGkmgCwVh/7Pl51YfBdIE1rIm/ngDvgdW8rNQ== 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 6: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 :) I concur, particularly given that nowadays, most modern and popular ARM64 SoCs are equipped with MTE. The absence of this patch also hinders the effective functioning of mTHP swap-out. > > >>> > >>> 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. right. > > > > >> 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. right. > > > > >> > >>> + 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