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 10906C433F5 for ; Fri, 27 May 2022 07:29:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1226D8D0006; Fri, 27 May 2022 03:29:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D1BD8D0002; Fri, 27 May 2022 03:29:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED9118D0006; Fri, 27 May 2022 03:29:44 -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 DEA028D0002 for ; Fri, 27 May 2022 03:29:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A44ED8087F for ; Fri, 27 May 2022 07:29:44 +0000 (UTC) X-FDA: 79510698288.23.71FAC03 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf03.hostedemail.com (Postfix) with ESMTP id 245C420031 for ; Fri, 27 May 2022 07:29:30 +0000 (UTC) Received: by mail-ej1-f48.google.com with SMTP id y13so7143397eje.2 for ; Fri, 27 May 2022 00:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BDUW6rhZr1cLhR+rXpmqy9X9Px+U0K54NN6ME+NGm0w=; b=J81AIv0ninxPsK+gQDpUH1BvmDMali0IwW/XEiCZg7Hc9VUFughyGMo065vFuqVfDu dE9I/bDKj6dwmLnJ5mGgfgyBkVnq32OKCVvDOv8VhcehHU68q6LXBlygAhBGKDR0nUIg aIvo1V2QLfQar9rhQttlSdETFEsk2X2mEF7/3JkJJgnf/9SMO7LKKtIkevV3BLElAsLm i/8ISMQ5fMMXRpsSmdKttsolIIm67I1gBi/RyHdpznXOUbbjXzWC3ZuN6fp8i+klIeNd 4wxhROO6nrWRSIacgqQELpL/G/u7GcfaRhzgHFvKHof8ftWl3KuaPsEfQhcwh8D0rl1c vTSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BDUW6rhZr1cLhR+rXpmqy9X9Px+U0K54NN6ME+NGm0w=; b=4ZLLCs7PniaQ8oyn7DzpWebOND17cEiq7S5VLHTO/+kHUtOjtK+eS8tbMzEt8M+k+K Bq2GMEhIhk1J252FAmq2UuwylmVLA+x4XR1930GU3V49DYYDCJ1vbtKOnzz7O+ymT3jc oZC8eQhCKEFralD9wnTimfrbyvpzsjqsYE5SN7jdn++dlltV5tGpvLKt1WNfW6XHmzIi me3D3q+JwdKTHywvFmgzAw4wzVdCH5kzR9AZ/lB/zZLlnp0Ms4K/Ov0BfaRlreQegty4 CeKHnI3E3xuKUb4hP+l2G5yO2R46zYjoCDg6AazvxvsYVq4af8GWvCokKqahtGt1/XdG NlMA== X-Gm-Message-State: AOAM532V7bSDptQsvYoQGtirXAB5/zFKQlgiI9BQ/YHF7AP57OrjZh1c f49pqXkAcXeU7dYZEQsYxkQsdc9JrdexciUQUbA= X-Google-Smtp-Source: ABdhPJyHaKMIF9secUpoEPTz2GjzeXQBMLBCB8/ETFYokgbxBRCEwTq6H5+2qeZ5TsLSiuYyTS2ymXgonycrkERveaM= X-Received: by 2002:a17:907:2d10:b0:6fe:debf:bfc7 with SMTP id gs16-20020a1709072d1000b006fedebfbfc7mr22026687ejc.502.1653636582760; Fri, 27 May 2022 00:29:42 -0700 (PDT) MIME-Version: 1.0 References: <20220524071403.128644-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 27 May 2022 19:29:31 +1200 Message-ID: Subject: Re: [PATCH] arm64: enable THP_SWAP for arm64 To: Yang Shi Cc: Catalin Marinas , Andrew Morton , Will Deacon , Linux-MM , LAK , LKML , hanchuanhua , =?UTF-8?B?5byg6K+X5piOKFNpbW9uIFpoYW5nKQ==?= , =?UTF-8?B?6YOt5YGl?= , Barry Song , "Huang, Ying" , Minchan Kim , Johannes Weiner , Hugh Dickins , Andrea Arcangeli , Steven Price Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=J81AIv0n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 245C420031 X-Stat-Signature: rmmefzqfpt1fc7cihqk1shwam3m6nck1 X-HE-Tag: 1653636570-667755 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: On Fri, May 27, 2022 at 5:03 AM Yang Shi wrote: > > On Thu, May 26, 2022 at 2:19 AM Barry Song <21cnbao@gmail.com> wrote: > > > > On Thu, May 26, 2022 at 5:49 AM Yang Shi wrote: > > > > > > On Wed, May 25, 2022 at 4:10 AM Barry Song <21cnbao@gmail.com> wrote: > > > > > > > > On Wed, May 25, 2022 at 7:14 AM Catalin Marinas wrote: > > > > > > > > > > On Tue, May 24, 2022 at 10:05:35PM +1200, Barry Song wrote: > > > > > > On Tue, May 24, 2022 at 8:12 PM Catalin Marinas wrote: > > > > > > > On Tue, May 24, 2022 at 07:14:03PM +1200, Barry Song wrote: > > > > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > > > > > > index d550f5acfaf3..8e3771c56fbf 100644 > > > > > > > > --- a/arch/arm64/Kconfig > > > > > > > > +++ b/arch/arm64/Kconfig > > > > > > > > @@ -98,6 +98,7 @@ config ARM64 > > > > > > > > select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36) > > > > > > > > select ARCH_WANT_LD_ORPHAN_WARN > > > > > > > > select ARCH_WANTS_NO_INSTR > > > > > > > > + select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES > > > > > > > > > > > > > > I'm not opposed to this but I think it would break pages mapped with > > > > > > > PROT_MTE. We have an assumption in mte_sync_tags() that compound pages > > > > > > > are not swapped out (or in). With MTE, we store the tags in a slab > > > > > > > > > > > > I assume you mean mte_sync_tags() require that THP is not swapped as a whole, > > > > > > as without THP_SWP, THP is still swapping after being splitted. MTE doesn't stop > > > > > > THP from swapping through a couple of splitted pages, does it? > > > > > > > > > > That's correct, split THP page are swapped out/in just fine. > > > > > > > > > > > > object (128-bytes per swapped page) and restore them when pages are > > > > > > > swapped in. At some point we may teach the core swap code about such > > > > > > > metadata but in the meantime that was the easiest way. > > > > > > > > > > > > If my previous assumption is true, the easiest way to enable THP_SWP > > > > > > for this moment might be always letting mm fallback to the splitting > > > > > > way for MTE hardware. For this moment, I care about THP_SWP more as > > > > > > none of my hardware has MTE. > > > > > > > > > > > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > > > > > > index 45c358538f13..d55a2a3e41a9 100644 > > > > > > --- a/arch/arm64/include/asm/pgtable.h > > > > > > +++ b/arch/arm64/include/asm/pgtable.h > > > > > > @@ -44,6 +44,8 @@ > > > > > > __flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1) > > > > > > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > > > > > > > > > > > > +#define arch_thp_swp_supported !system_supports_mte > > > > > > + > > > > > > /* > > > > > > * Outside of a few very special situations (e.g. hibernation), we always > > > > > > * use broadcast TLB invalidation instructions, therefore a spurious page > > > > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > > > > > index 2999190adc22..064b6b03df9e 100644 > > > > > > --- a/include/linux/huge_mm.h > > > > > > +++ b/include/linux/huge_mm.h > > > > > > @@ -447,4 +447,16 @@ static inline int split_folio_to_list(struct folio *folio, > > > > > > return split_huge_page_to_list(&folio->page, list); > > > > > > } > > > > > > > > > > > > +/* > > > > > > + * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to > > > > > > + * limitations in the implementation like arm64 MTE can override this 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/mm/swap_slots.c b/mm/swap_slots.c > > > > > > index 2b5531840583..dde685836328 100644 > > > > > > --- a/mm/swap_slots.c > > > > > > +++ b/mm/swap_slots.c > > > > > > @@ -309,7 +309,7 @@ swp_entry_t get_swap_page(struct page *page) > > > > > > entry.val = 0; > > > > > > > > > > > > if (PageTransHuge(page)) { > > > > > > - if (IS_ENABLED(CONFIG_THP_SWAP)) > > > > > > + if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_supported()) > > > > > > get_swap_pages(1, &entry, HPAGE_PMD_NR); > > > > > > goto out; > > > > > > > > > > I think this should work and with your other proposal it would be > > > > > limited to MTE pages: > > > > > > > > > > #define arch_thp_swp_supported(page) (!test_bit(PG_mte_tagged, &page->flags)) > > > > > > > > > > Are THP pages loaded from swap as a whole or are they split? IIRC the > > > > > > > > i can confirm thp is written as a whole through: > > > > [ 90.622863] __swap_writepage+0xe8/0x580 > > > > [ 90.622881] swap_writepage+0x44/0xf8 > > > > [ 90.622891] pageout+0xe0/0x2a8 > > > > [ 90.622906] shrink_page_list+0x9dc/0xde0 > > > > [ 90.622917] shrink_inactive_list+0x1ec/0x3c8 > > > > [ 90.622928] shrink_lruvec+0x3dc/0x628 > > > > [ 90.622939] shrink_node+0x37c/0x6a0 > > > > [ 90.622950] balance_pgdat+0x354/0x668 > > > > [ 90.622961] kswapd+0x1e0/0x3c0 > > > > [ 90.622972] kthread+0x110/0x120 > > > > > > > > but i have never got a backtrace in which thp is loaded as a whole though it > > > > seems the code has this path: > > > > > > THP could be swapped out in a whole, but never swapped in as THP. Just > > > the single base page (4K on x86) is swapped in. > > > > yep. it seems swapin_readahead() is never reading a THP or even splitted > > pages for this 2MB THP. > > > > the number of pages to be read-ahead is determined either by > > /proc/sys/vm/page-cluster if /sys/kernel/mm/swap/vma_ra_enabled is fase > > or > > by vma read-ahead algorithm if /sys//kernel/mm/swap/vma_ra_enabled is true > > And the number is usually quite small. > > > > Am I missing any case in which 2MB can be swapped in as whole either by > > splitted pages or a THP? > > Even though readahead swaps in 2MB, they are 512 single base pages > rather than THP. They may not be physically continuous at all. I actually haven't found out that readahead can swap in 2MB through either THP or 512 single base pages. per my log, swapin_vma_readahead() usually swaps in 2,3,4 or 8 pages. but we do have a case in which we can swap in up to 2MB while doing collapse: static bool __collapse_huge_page_swapin(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long haddr, pmd_t *pmd, int referenced) { int swapped_in = 0; vm_fault_t ret = 0; unsigned long address, end = haddr + (HPAGE_PMD_NR * PAGE_SIZE); for (address = haddr; address < end; address += PAGE_SIZE) { struct vm_fault vmf = { .vma = vma, .address = address, .pgoff = linear_page_index(vma, haddr), .flags = FAULT_FLAG_ALLOW_RETRY, .pmd = pmd, }; vmf.pte = pte_offset_map(pmd, address); vmf.orig_pte = *vmf.pte; if (!is_swap_pte(vmf.orig_pte)) { pte_unmap(vmf.pte); continue; } swapped_in++; ret = do_swap_page(&vmf); ...} } } It seems Huang Ying once mentioned there was a plan to not split THP throughout the whole process. Thanks Barry