Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4116448imw; Mon, 18 Jul 2022 23:11:22 -0700 (PDT) X-Google-Smtp-Source: AGRyM1srvsPygV5B5Q/3b1KdHPabJK5ufkKMMCU+cqg3nqIHjydCbdR4ANuSh8+a8O3XQtbcx/Dl X-Received: by 2002:a17:907:28ca:b0:72b:110a:b34e with SMTP id en10-20020a17090728ca00b0072b110ab34emr29159046ejc.113.1658211081997; Mon, 18 Jul 2022 23:11:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658211081; cv=none; d=google.com; s=arc-20160816; b=nDwwal7j0WtBKk2HDFyK5bZjyUCaixuQZ3j1EzC1NfQL7IeZkyGuLMMYYbZRMCGrkn 2Ic35n5abw6Y3LjoGsysPa0VQONgcKG67mDeSu1WAPy2cQPzMp4RVM68bEATPa+GYel/ CPjjzOEfb60cEGGQoh+NrBcO9mtxIOJGRmNP4UFykZTaQamwmA9VTQSIfI1oSrAvSp24 c/zZb+EbVZ+3JZRyDqx4iq+zjmhvJIL3iKc/V3ydcvOI5D6WEKMm8MKHA24oOgM0mxFV W+9p+7cGEB0iZTqogyOhQV+STeFS/M2JDFSGeFPhYG8ANmseLS9gg2TgLPWHvcq+qEh1 EGxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature; bh=at8EX1g9AgznRBN2wunOA3OPFYfZPYmK0U/XcQzOgRE=; b=VoL7Iibprayv445mlMOLlmTF2rTF9sw0PfiIhgKKJkRxocLBurl1LMJck5lsGpPLP3 F6pdza/Bmm7Dv1eBxRYFafsT4Zms0GwmcQK8v4zv1lKrjzUU1IX2W8ZBQSBv58KcGjOf Ia1A0g2WxDTPxEDMv95sRrGbgzZNowbUivpnNiftutC73qh4PiWzQo1SnqnSGHyQUavm tSNz0tOobvAOv+TH/EFKk3LabGlj3U19wVUCko5L7K9YjeypxVu/jna5J9BL6i1hMjI5 cRy3WxHT7rT6MtZlU/zGlOkwIK+NC5XY78+JUPA3P7aU27RzAW6EP4GS6UF5Vmc+/GPo 8CgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Y/VdrRki"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l21-20020a170906645500b00717917b7d9bsi16038698ejn.334.2022.07.18.23.10.57; Mon, 18 Jul 2022 23:11:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Y/VdrRki"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235622AbiGSFrH (ORCPT + 99 others); Tue, 19 Jul 2022 01:47:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230447AbiGSFrG (ORCPT ); Tue, 19 Jul 2022 01:47:06 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 421E225596 for ; Mon, 18 Jul 2022 22:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658209623; x=1689745623; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=jmjeSdIDmrExnySMY5k5cqgszPtMtpWqsk3OgxRtt0A=; b=Y/VdrRki2kEdloeujS+kqnMjbYcfvrFnxqI7j9IeDgYYULdIW5feT0TH mWoSoLYLI1MBbQ+fZvNwzxjb2W8GxUpGmjgAOW//ldL/o+m+d6E/P04Xi cZa38iH6aQcegy+6m0c4Xuc4CCHIH8mXxXR9Poc9vwkR6lgkESEwq20D2 5UADd3bS3cBDThm5n2StZjfXcPBtvlg7lSnP4auIwl9NXTexPsdEq1ycJ HvZmbtYnYE5obwHCnTxTo3I+HyhC8Inhjrn2iD71DEdqVMWwj4ktJZwHe AYgPp6M6J79RsHBDK58ZpxLe4YZq0gk7Iwfvtwsue1NAPgGBDhw32zcGZ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="285154842" X-IronPort-AV: E=Sophos;i="5.92,283,1650956400"; d="scan'208";a="285154842" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 22:47:03 -0700 X-IronPort-AV: E=Sophos;i="5.92,283,1650956400"; d="scan'208";a="665293232" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 22:46:59 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> Cc: Anshuman Khandual , Andrew Morton , Catalin Marinas , LAK , Linux-MM , Steven Price , Will Deacon , Andrea Arcangeli , =?utf-8?B?6YOt5YGl?= , hanchuanhua , Johannes Weiner , Hugh Dickins , LKML , Minchan Kim , Yang Shi , Barry Song , =?utf-8?B?5byg6K+X5piOKFNpbW9uIFpoYW5nKQ==?= Subject: Re: [RESEND PATCH v3] arm64: enable THP_SWAP for arm64 References: <20220718090050.2261-1-21cnbao@gmail.com> <87mtd62apo.fsf@yhuang6-desk2.ccr.corp.intel.com> <87zgh5232o.fsf@yhuang6-desk2.ccr.corp.intel.com> <416a06f6-ca7d-d4a9-2cda-af0ad6e28261@arm.com> Date: Tue, 19 Jul 2022 13:46:24 +0800 In-Reply-To: (Barry Song's message of "Tue, 19 Jul 2022 16:03:10 +1200") Message-ID: <87o7xl1wpb.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Barry Song <21cnbao@gmail.com> writes: > On Tue, Jul 19, 2022 at 3:59 PM Barry Song <21cnbao@gmail.com> wrote: >> >> On Tue, Jul 19, 2022 at 3:35 PM Anshuman Khandual >> wrote: >> > >> > >> > >> > On 7/19/22 08:58, Huang, Ying wrote: >> > > Anshuman Khandual writes: >> > > >> > >> On 7/19/22 06:53, Barry Song wrote: >> > >>> On Tue, Jul 19, 2022 at 12:44 PM Huang, Ying wrote: >> > >>>> >> > >>>> Barry Song <21cnbao@gmail.com> writes: >> > >>>> >> > >>>>> From: Barry Song >> > >>>>> >> > >>>>> THP_SWAP has been proven 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. THP_SWAP is architecture-independent, thus, >> > >>>>> enabling it on arm64 will benefit arm64 as well. >> > >>>>> A corner case is that MTE has an assumption that only base pages >> > >>>>> can be swapped. We won't enable THP_SWAP for ARM64 hardware with >> > >>>>> MTE support until MTE is reworked to coexist with THP_SWAP. >> > >>>>> >> > >>>>> A micro-benchmark is written to measure thp swapout throughput as >> > >>>>> below, >> > >>>>> >> > >>>>> unsigned long long tv_to_ms(struct timeval tv) >> > >>>>> { >> > >>>>> return tv.tv_sec * 1000 + tv.tv_usec / 1000; >> > >>>>> } >> > >>>>> >> > >>>>> main() >> > >>>>> { >> > >>>>> struct timeval tv_b, tv_e;; >> > >>>>> #define SIZE 400*1024*1024 >> > >>>>> volatile void *p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, >> > >>>>> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); >> > >>>>> if (!p) { >> > >>>>> perror("fail to get memory"); >> > >>>>> exit(-1); >> > >>>>> } >> > >>>>> >> > >>>>> madvise(p, SIZE, MADV_HUGEPAGE); >> > >>>>> memset(p, 0x11, SIZE); /* write to get mem */ >> > >>>>> >> > >>>>> gettimeofday(&tv_b, NULL); >> > >>>>> madvise(p, SIZE, MADV_PAGEOUT); >> > >>>>> gettimeofday(&tv_e, NULL); >> > >>>>> >> > >>>>> printf("swp out bandwidth: %ld bytes/ms\n", >> > >>>>> SIZE/(tv_to_ms(tv_e) - tv_to_ms(tv_b))); >> > >>>>> } >> > >>>>> >> > >>>>> Testing is done on rk3568 64bit quad core processor Quad Core >> > >>>>> Cortex-A55 platform - ROCK 3A. >> > >>>>> thp swp throughput w/o patch: 2734bytes/ms (mean of 10 tests) >> > >>>>> thp swp throughput w/ patch: 3331bytes/ms (mean of 10 tests) >> > >>>>> >> > >>>>> Cc: "Huang, Ying" >> > >>>>> Cc: Minchan Kim >> > >>>>> Cc: Johannes Weiner >> > >>>>> Cc: Hugh Dickins >> > >>>>> Cc: Andrea Arcangeli >> > >>>>> Cc: Anshuman Khandual >> > >>>>> Cc: Steven Price >> > >>>>> Cc: Yang Shi >> > >>>>> Signed-off-by: Barry Song >> > >>>>> --- >> > >>>>> -v3: >> > >>>>> * refine the commit log; >> > >>>>> * add a benchmark result; >> > >>>>> * refine the macro of arch_thp_swp_supported >> > >>>>> Thanks to the comments of Anshuman, Andrew, Steven >> > >>>>> >> > >>>>> arch/arm64/Kconfig | 1 + >> > >>>>> arch/arm64/include/asm/pgtable.h | 6 ++++++ >> > >>>>> include/linux/huge_mm.h | 12 ++++++++++++ >> > >>>>> mm/swap_slots.c | 2 +- >> > >>>>> 4 files changed, 20 insertions(+), 1 deletion(-) >> > >>>>> >> > >>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> > >>>>> index 1652a9800ebe..e1c540e80eec 100644 >> > >>>>> --- a/arch/arm64/Kconfig >> > >>>>> +++ b/arch/arm64/Kconfig >> > >>>>> @@ -101,6 +101,7 @@ config ARM64 >> > >>>>> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >> > >>>>> select ARCH_WANT_LD_ORPHAN_WARN >> > >>>>> select ARCH_WANTS_NO_INSTR >> > >>>>> + select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES >> > >>>>> select ARCH_HAS_UBSAN_SANITIZE_ALL >> > >>>>> select ARM_AMBA >> > >>>>> select ARM_ARCH_TIMER >> > >>>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> > >>>>> index 0b6632f18364..78d6f6014bfb 100644 >> > >>>>> --- a/arch/arm64/include/asm/pgtable.h >> > >>>>> +++ b/arch/arm64/include/asm/pgtable.h >> > >>>>> @@ -45,6 +45,12 @@ >> > >>>>> __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 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 de29821231c9..4ddaf6ad73ef 100644 >> > >>>>> --- a/include/linux/huge_mm.h >> > >>>>> +++ b/include/linux/huge_mm.h >> > >>>>> @@ -461,4 +461,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; >> > >>>>> +} >> > >>>> >> > >>>> How about the following? >> > >>>> >> > >>>> static inline bool arch_wants_thp_swap(void) >> > >>>> { >> > >>>> return IS_ENABLED(ARCH_WANTS_THP_SWAP); >> > >>>> } >> > >>> >> > >>> This looks good. then i'll need to change arm64 to >> > >>> >> > >>> +static inline bool arch_thp_swp_supported(void) >> > >>> +{ >> > >>> + return IS_ENABLED(ARCH_WANTS_THP_SWAP) && !system_supports_mte(); >> > >>> +} >> > >> >> > >> Why ? CONFIG_THP_SWAP depends on ARCH_WANTS_THP_SWAP. In folio_alloc_swap(), >> > >> IS_ENABLED(CONFIG_THP_SWAP) enabled, will also imply ARCH_WANTS_THP_SWAP too >> > >> is enabled. Hence checking for ARCH_WANTS_THP_SWAP again does not make sense >> > >> either in the generic fallback stub, or in arm64 platform override. Because >> > >> without ARCH_WANTS_THP_SWAP enabled, arch_thp_swp_supported() should never >> > >> be called in the first place. >> > > >> > > For the only caller now, the checking looks redundant. But the original >> > > proposed implementation as follows, >> > > >> > > static inline bool arch_thp_swp_supported(void) >> > > { >> > > return true; >> > > } >> > > >> > > will return true even on architectures that don't support/want THP swap. >> > >> > But the function will never be called on for those platforms. >> > >> > > That will confuse people too. >> > >> > I dont see how. >> > >> > > >> > > And the "redundant" checking has no run time overhead, because compiler >> > > will do the trick. >> > I understand that, but dont think this indirection is necessary. >> >> Hi Anshuman, Hi Ying, >> Thanks for the comments of both of you. Does the below look ok? >> >> generic, >> >> static inline bool arch_wants_thp_swap(void) >> { >> return IS_ENABLED(CONFIG_THP_SWAP); >> } >> > > sorry, i actually meant arch_thp_swp_supported() but not > arch_wants_thp_swap() in generic code, > > static inline bool arch_thp_swp_supported(void) > { > return IS_ENABLED(CONFIG_THP_SWAP); > } IS_ENABLED(CONFIG_THP_SWAP) doesn't match the name too. It's an option selected by users. arch_thp_swp_supported() is to report the capability. Best Regards, Huang, Ying >> arm64, >> >> static inline bool arch_thp_swp_supported(void) >> { >> return IS_ENABLED(CONFIG_THP_SWAP) && !system_supports_mte(); >> } >> >> caller, >> >> folio_alloc_swap(struct folio *folio) >> { >> >> if (folio_test_large(folio)) { >> - if (IS_ENABLED(CONFIG_THP_SWAP)) >> + if (arch_thp_swp_supported()) >> get_swap_pages(1, &entry, folio_nr_pages(folio)); >> goto out; >> } >> >> Thanks >> Barry