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 9699EEB64DA for ; Tue, 4 Jul 2023 12:36:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 178E16B0088; Tue, 4 Jul 2023 08:36:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 129566B0089; Tue, 4 Jul 2023 08:36:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3342280075; Tue, 4 Jul 2023 08:36:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E26096B0088 for ; Tue, 4 Jul 2023 08:36:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AF491160AC3 for ; Tue, 4 Jul 2023 12:36:39 +0000 (UTC) X-FDA: 80973878118.05.ECAD9B4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf08.hostedemail.com (Postfix) with ESMTP id C3368160019 for ; Tue, 4 Jul 2023 12:36:36 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688474197; 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; bh=JtsB2i0BoWuUDq/m1xRMtYa5j4LlVaDVljlF69zN/k8=; b=dx9euMjkmd88GylGCbP9W4+WCLZhr7xttX9immOnNazbhkra/YLUXm0iHHorf3ifbdng2s bbWfHLnFRzj79RwKo1BLR3hsl6X5grD7nEoI1aU9VZflZ7Sro3fS0W5hOhPEkZ0FEj8r/v QGMKJdRdHNt3/3VqiQw9bMuutYau9L8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688474197; a=rsa-sha256; cv=none; b=Q+JSwmXLyYnKUqgI3iL0pEduXUtvNmcWud5cLg1hMD4i0/Jan0kzJaLrcoCLnme0CgsXtu tKkTqTe7v3uzLq8SniCoM3hBe5Py+1MlasMih9LOMajSpx3oG+LG2KEDJHIoWOsJm3gY1U HKhTZSOwSIOqbrkJhCcg3MmkeFemKoQ= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1738F2F4; Tue, 4 Jul 2023 05:37:18 -0700 (PDT) Received: from [10.1.35.40] (C02Z41KALVDN.cambridge.arm.com [10.1.35.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0FC6E3F762; Tue, 4 Jul 2023 05:36:33 -0700 (PDT) Message-ID: <6d389825-1fc0-5c16-7858-2290fd632682@arm.com> Date: Tue, 4 Jul 2023 13:36:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 3/5] mm: Default implementation of arch_wants_pte_order() To: Yu Zhao , "Yin, Fengwei" Cc: Andrew Morton , Matthew Wilcox , "Kirill A. Shutemov" , David Hildenbrand , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230703135330.1865927-1-ryan.roberts@arm.com> <20230703135330.1865927-4-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C3368160019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: u133imrn99wb9zzfj41u9hcfe5akfrat X-HE-Tag: 1688474196-305060 X-HE-Meta: U2FsdGVkX1/ctAya0AftDquCGisBwzk3glwJyt4Gi64e1PYFs78VKNoLEKOiiNAOUe0T6pYYPVTC9F4W0YGwJqtjkAXH4d7Ef54qz1M72LgCyY8NJtHnvWVx9NRFJeSzfDZ8s4b1hXtQjQTDz1LldtKd5GkOOboEy7ylDGJQ0BUek8yADsTRrplJoI8PLSdwdy6LMH1NGVYqHT8aGTu2oq3B2W0PcfYLAJxmhXh5egmsMV7H3Odaz5pB7fPZjQartEs82srU81jd1fMP6M5wXCz2sOFY/h4jrlG8GUwfWJp0k2uxl25RaDQU3EzA9QVK0rHvjhC7Ye+J8/JJtTVn2pAMn2ROv610Fy2l6uBovWdyIzJ2f5KbOc6hpzRvARgCieMn1zOqtGc2AbDhTdLYBTNTEYJx/lGyvdFKPoZVu9n+pkKNH95gqpp7fO+SBf4HrMHIdRi9SdaCZm9Xej47GX41V8s8lELaLgxIf4zk3ZZpXq1RGyxWPeAi+cMGTsWJnYiZTAm3tMrLaDW1RCG0CBXMgJuYJjflyy5yWwrU3ulKt88Ww19BIVJXSSMFjTc5pM1PvAthv9jr5kgOcaUy/ELt9lON47GeKCrHFsZaLBio6ybAjpt9SYEW9HsKXlaTNkUwaVpHeeDX5Mq8ndhIR+4GHS7AL6BOUenYUQtmnEG05UsxRI8oyZ4LgjNS1jQ12M/napPqPdsGAnd0P2ewQeXZJX3vdnP2dI3Lmv1Ei02S8QzCk7TBIJdnouuU2P9zysZmJXpHXOpdhEfkxjVXxfCPoIpXHCKJzvsLy0jYmj/LkCZbt5vFFskgVjHQIdsucMxEmJkZK3jQEYwop6WIAOaw/ZsqJSqVgpGRCB+eOkAIh4gu7mHxqJmCW2uOmfJ0NEMo7ZxFJfYYb4qxMX6EeKck2AZOxQKyh2PffeQqTR4fWPoSdgMc9/6FicvIlqpL4fRUYznrWspM5INbGMQ TnqDBidJ YmxpQTLsTeyOjYTFZPHfNFziCUih4g6+Y0J9nTtlaHRVjdbQ+TuqXh96DOBGphT7b5lUSr1nAWtoY6V3j2LHqGxAXmi2n0YRDc5+d4UormcgqiJUmEAd3E+KqL8xY1NiPOWuXRB764w6ttPGPnoNgpsleNun9cqBnE9f2W2yRn2l6kI3QI6kOhqs5NLp+eK+gzPE255RbjNDN0h+URoUEcQNziQqlhOid/NKXBcraKHSfDim7POBAVbPBsfUXCjb+3YyezQdkTb+ESL0= 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 04/07/2023 04:59, Yu Zhao wrote: > On Mon, Jul 3, 2023 at 9:02 PM Yu Zhao wrote: >> >> On Mon, Jul 3, 2023 at 8:23 PM Yin, Fengwei wrote: >>> >>> >>> >>> On 7/3/2023 9:53 PM, Ryan Roberts wrote: >>>> arch_wants_pte_order() can be overridden by the arch to return the >>>> preferred folio order for pte-mapped memory. This is useful as some >>>> architectures (e.g. arm64) can coalesce TLB entries when the physical >>>> memory is suitably contiguous. >>>> >>>> The first user for this hint will be FLEXIBLE_THP, which aims to >>>> allocate large folios for anonymous memory to reduce page faults and >>>> other per-page operation costs. >>>> >>>> Here we add the default implementation of the function, used when the >>>> architecture does not define it, which returns the order corresponding >>>> to 64K. >>>> >>>> Signed-off-by: Ryan Roberts >>>> --- >>>> include/linux/pgtable.h | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >>>> index a661a17173fa..f7e38598f20b 100644 >>>> --- a/include/linux/pgtable.h >>>> +++ b/include/linux/pgtable.h >>>> @@ -13,6 +13,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #if 5 - defined(__PAGETABLE_P4D_FOLDED) - defined(__PAGETABLE_PUD_FOLDED) - \ >>>> defined(__PAGETABLE_PMD_FOLDED) != CONFIG_PGTABLE_LEVELS >>>> @@ -336,6 +337,18 @@ static inline bool arch_has_hw_pte_young(void) >>>> } >>>> #endif >>>> >>>> +#ifndef arch_wants_pte_order >>>> +/* >>>> + * Returns preferred folio order for pte-mapped memory. Must be in range [0, >>>> + * PMD_SHIFT-PAGE_SHIFT) and must not be order-1 since THP requires large folios >>>> + * to be at least order-2. >>>> + */ >>>> +static inline int arch_wants_pte_order(struct vm_area_struct *vma) >>>> +{ >>>> + return ilog2(SZ_64K >> PAGE_SHIFT); >>> Default value which is not related with any silicon may be: PAGE_ALLOC_COSTLY_ORDER? >>> >>> Also, current pcp list support cache page with order 0...PAGE_ALLOC_COSTLY_ORDER, 9. >>> If the pcp could cover the page, the pressure to zone lock will be reduced by pcp. >> >> The value of PAGE_ALLOC_COSTLY_ORDER is reasonable but again it's a >> s/w policy not a h/w preference. Besides, I don't think we can include >> mmzone.h in pgtable.h. > > I think we can make a compromise: > 1. change the default implementation of arch_has_hw_pte_young() to return 0, and > 2. in memory.c, we can try PAGE_ALLOC_COSTLY_ORDER for archs that > don't override arch_has_hw_pte_young(), or if its return value is too > large to fit. > This should also take care of the regression, right? I think you are suggesting that we use 0 as a sentinel which we then translate to PAGE_ALLOC_COSTLY_ORDER? I already have a max_anon_folio_order() function in memory.c (actually it is currently a macro defined as arch_wants_pte_order()). So it would become (I'll talk about the vma concern separately in the thread where you raised it): static inline int max_anon_folio_order(struct vm_area_struct *vma) { int order = arch_wants_pte_order(vma); return order ? order : PAGE_ALLOC_COSTLY_ORDER; } Correct? I don't see how it fixes the regression (assume you're talking about Speedometer) though? On arm64 arch_wants_pte_order() will still be returning order-4.