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 DF3E6C433EF for ; Tue, 24 May 2022 11:15:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2999C8D0005; Tue, 24 May 2022 07:15:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 245DF8D0002; Tue, 24 May 2022 07:15:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10F898D0005; Tue, 24 May 2022 07:15:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F2FF98D0002 for ; Tue, 24 May 2022 07:15:33 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AF98C347FE for ; Tue, 24 May 2022 11:15:33 +0000 (UTC) X-FDA: 79500380946.13.3405820 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf21.hostedemail.com (Postfix) with ESMTP id 7F18B1C002E for ; Tue, 24 May 2022 11:15:21 +0000 (UTC) Received: by mail-ej1-f45.google.com with SMTP id f21so20947469ejh.11 for ; Tue, 24 May 2022 04:15:33 -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=rm0MWZbX6R/By7K+rxlAjoioJpGDi/eaTT4NYHz6bcU=; b=F9WLWYTdXocg+MPoUgp4Bf7Vi2qbilJV7BvoS7du8d97TITGv82B6ypzkLX/NSe8R2 BxCTLrLu0NQFYr4MRubjlRXjz4i77w1w8XK2Bdak0/r4QFXWBRI49z9Z6puikhaly3PV IzNX36O5RCXi30MeO/4+9MRmqhleiWTunupiKaW6aQ4i8tnu7w9sqn36B+OvLQnoKg4E 3luQfMQ+n5Vfzso85P6EMZStdIWEeoU1QuMVAq/2X6sIQjL9QBFR0aaKazYlul/D9vyb XDdW0i9dMpOUDMoRwyzShBzkzsi6g/U4AY04vJOkS03RteG+iE2+tu6c3mVKK1pTE/ma 5nCw== 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=rm0MWZbX6R/By7K+rxlAjoioJpGDi/eaTT4NYHz6bcU=; b=HyAxPJQZT47bFCfLnkZLl8h40q1vI3Z9tGsq6cKFqsdh/5pmhUWr41Wo8ShOu1fgbC HL14uRrRGiPBydJ0XClhMt+nX/H7pGHscfmpd/9+DZbFpEyNn/ZcCdNyb/u8OkoTn8BU wlQdr+LLE+2qxWUUX2d5YY2rQTPoMswabaM4x2w3qIwSejnvlsxc46d9ULHmmFyTIyFL 8GypBpgGFXQIaBW/ix1LvqOclNsp63FZQsuYVNVIRnlzvW59RmZJPAYUwqBCihm34IS+ 4xE+JD8ozqrTbVFeMbT3muWASfstPO5SwYQa1lQNBt3EcsorFHY1l2LewPKN4FbyhqMq kv0A== X-Gm-Message-State: AOAM530hp6xAEgRGNgxWHzcWQUsgoDpp4jkfehy/P3VqvMGcE5/w/7HJ kKjHxSHR+ovO10HX0n4X2gIQFtVLowIHpGTwiSk= X-Google-Smtp-Source: ABdhPJwkvi9Kxb+Y+IHF1mZiooqwN0jXvP5jliln7mmgkqu6mG3+RkPKm7KFoRaNqse5ZAXMqLmrCnd7aDN7ZM/Xmtc= X-Received: by 2002:a17:906:7309:b0:6f5:ea1:afa with SMTP id di9-20020a170906730900b006f50ea10afamr24026992ejc.170.1653390931817; Tue, 24 May 2022 04:15:31 -0700 (PDT) MIME-Version: 1.0 References: <20220524071403.128644-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 24 May 2022 23:15:20 +1200 Message-ID: Subject: Re: [PATCH] arm64: enable THP_SWAP for arm64 To: Catalin Marinas Cc: 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 , Shaohua Li , Rik van Riel , Andrea Arcangeli , Steven Price Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 7F18B1C002E X-Stat-Signature: oeqgyrr5nxcn4efkd9774g83xhfhtad7 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=F9WLWYTd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-Rspamd-Server: rspam04 X-HE-Tag: 1653390921-385269 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 Tue, May 24, 2022 at 10:05 PM Barry Song <21cnbao@gmail.com> 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: > > > From: Barry Song > > > > > > THP_SWAP has been proved to improve the swap throughput significantly > > > on x86_64 according to commit bd4c82c22c367e ("mm, THP, swap: delay > > > splitting THP after swapped out"). > > > As long as arm64 uses 4K page size, it is quite similar with x86_64 > > > by having 2MB PMD THP. So we are going to get similar improvement. > > > For other page sizes such as 16KB and 64KB, PMD might be too large. > > > Negative side effects such as IO latency might be a problem. Thus, > > > we can only safely enable the counterpart of X86_64. > > > > > > Cc: "Huang, Ying" > > > Cc: Minchan Kim > > > Cc: Johannes Weiner > > > Cc: Hugh Dickins > > > Cc: Shaohua Li > > > Cc: Rik van Riel > > > Cc: Andrea Arcangeli > > > Signed-off-by: Barry Song > > > --- > > > arch/arm64/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > 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? > > > 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; > } > Am I actually able to go further to only split MTE tagged pages? For mm core: +/* + * 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(struct page *page) +{ + return true; +} +#endif + For arm64: +#define arch_thp_swp_supported(page) !test_bit(PG_mte_tagged, &page->flags) But I don't have MTE hardware to test. So to me, totally disabling THP_SWP is safer. thoughts? > > -- > > Catalin > > Thanks > Barry