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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 83DCCCD1296 for ; Wed, 10 Apr 2024 10:25:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0XgwFVx8AZZNHxYqbeEVVCSAvPPOSsQj4BnAG1LErRk=; b=u6i2quFULMu5D9 gH6qRPxZufXWAUPQpTiLFfRMjlaT/Gs+uC4Fz2JLvQImYlJiT5/1KvwLXOlmptMdqWb1eWeQrZIeZ B1I0hu86536SppIdDDv+Q8rJEgnNkRNKGy16errnR8Rg1hA6NwLvS92HKtrHR53KL0hypIZvKhOrp 48eN2VXD5Mzve9vR68oaKbKqslalKagC/7kevfMYoMRzdDtLfTr4mixW15NuOkusmUylj/YMNsVMi QhTf/YRAnvlf5HqtPcCOhNPWJsI3nAAeJNuwwctUhDq5y+5FsnIIWVpLy2rsjVFSDrDI6u23OSg7i HEBsa/DyaNRlOdU2sIRg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruV8p-00000006NKI-2tRi; Wed, 10 Apr 2024 10:25:19 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruV8m-00000006NIu-3Ju3 for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2024 10:25:18 +0000 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 DC5EB139F; Wed, 10 Apr 2024 03:25:42 -0700 (PDT) Received: from [10.57.73.247] (unknown [10.57.73.247]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9859D3F6C4; Wed, 10 Apr 2024 03:25:11 -0700 (PDT) Message-ID: Date: Wed, 10 Apr 2024 11:25:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] arm64: mm: Batch dsb and isb when populating pgtables Content-Language: en-GB To: Mark Rutland Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , David Hildenbrand , Donald Dutile , Eric Chanudet , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Itaru Kitayama References: <20240404143308.2224141-1-ryan.roberts@arm.com> <20240404143308.2224141-3-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240410_032516_973436_1E3D56F1 X-CRM114-Status: GOOD ( 24.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/04/2024 11:06, Mark Rutland wrote: > On Thu, Apr 04, 2024 at 03:33:06PM +0100, Ryan Roberts wrote: >> After removing uneccessary TLBIs, the next bottleneck when creating the >> page tables for the linear map is DSB and ISB, which were previously >> issued per-pte in __set_pte(). Since we are writing multiple ptes in a >> given pte table, we can elide these barriers and insert them once we >> have finished writing to the table. >> >> Execution time of map_mem(), which creates the kernel linear map page >> tables, was measured on different machines with different RAM configs: >> >> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra >> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G >> ---------------|-------------|-------------|-------------|------------- >> | ms (%) | ms (%) | ms (%) | ms (%) >> ---------------|-------------|-------------|-------------|------------- >> before | 77 (0%) | 431 (0%) | 1727 (0%) | 3796 (0%) >> after | 13 (-84%) | 162 (-62%) | 655 (-62%) | 1656 (-56%) >> >> Signed-off-by: Ryan Roberts >> Tested-by: Itaru Kitayama >> Tested-by: Eric Chanudet >> --- >> arch/arm64/include/asm/pgtable.h | 7 ++++++- >> arch/arm64/mm/mmu.c | 13 ++++++++++++- >> 2 files changed, 18 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index afdd56d26ad7..105a95a8845c 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -271,9 +271,14 @@ static inline pte_t pte_mkdevmap(pte_t pte) >> return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL)); >> } >> >> -static inline void __set_pte(pte_t *ptep, pte_t pte) >> +static inline void __set_pte_nosync(pte_t *ptep, pte_t pte) >> { >> WRITE_ONCE(*ptep, pte); >> +} >> + >> +static inline void __set_pte(pte_t *ptep, pte_t pte) >> +{ >> + __set_pte_nosync(ptep, pte); >> >> /* >> * Only if the new pte is valid and kernel, otherwise TLB maintenance >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index fd91b5bdb514..dc86dceb0efe 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -178,7 +178,11 @@ static pte_t *init_pte(pte_t *ptep, unsigned long addr, unsigned long end, >> do { >> pte_t old_pte = __ptep_get(ptep); >> >> - __set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot)); >> + /* >> + * Required barriers to make this visible to the table walker >> + * are deferred to the end of alloc_init_cont_pte(). >> + */ >> + __set_pte_nosync(ptep, pfn_pte(__phys_to_pfn(phys), prot)); >> >> /* >> * After the PTE entry has been populated once, we >> @@ -234,6 +238,13 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr, >> } while (addr = next, addr != end); >> >> pte_clear_fixmap(); >> + >> + /* >> + * Ensure all previous pgtable writes are visible to the table walker. >> + * See init_pte(). >> + */ >> + dsb(ishst); >> + isb(); > > Hmm... currently the call to pte_clear_fixmap() alone should be sufficient, > since that needs to update the PTE for the fixmap slot, then do maintenance for > that. Yes, true... > > So we could avoid the addition of the dsb+isb here, and have a comment: > > /* > * Note: barriers and maintenance necessary to clear the fixmap slot > * ensure that all previous pgtable writes are visible to the table > * walker. > */ > pte_clear_fixmap(); > > ... which'd be fine as long as we keep this fixmap clearing rather than trying > to do that lazily as in patch 4. But it isn't patch 4 that breaks it, it's patch 3. Once we have abstracted pte_clear_fixmap() into the ops->unmap() call, for the "late" ops, unmap is a noop. I guess the best solution there would be to require that unmap() always issues these barriers. I'll do as you suggest for this patch. If we want to keep patch 3, then I'll add the barriers for all unmap() impls. > > Mark. > >> } >> >> static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end, >> -- >> 2.25.1 >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel