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 9A17BC3DA7D for ; Tue, 3 Jan 2023 13:07:55 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wrotenAmQJa6xH8lf779tqxA//gla424plJRhEqFZA0=; b=Ns0C9K9771zZ3b rX6goMo7c77Z2rTC3asTCt+ozfVqS2xd00npxg7JhmiFdD97kTDfiqG9syKQ9ECBavc72v2tu6txe aievB9Li6kL/5UvOMS5Y6zIDqm1CJEkKOZPiVSIfw7t/OpvH64yYl4s6+scUFy3iqwUPnMMWvEvUp jta6eQvL5OmwmSyQyyw5boQMNpjZS8gBH1kO8k9fgPtveA1wrLMG+irc1JgepiLUxbOGdISwWDZLE dEvzv9K6REOtt3TbG2aSm4m+NUgHXVfK2o9BnSxBKXU1oTznrf2ZIY8oY+Aw93Ggo1vHYbWM1GNsg epSJFzhgE1NQevdRv3sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCgzz-001ORm-4N; Tue, 03 Jan 2023 13:06:35 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCfAw-000udp-8n for linux-arm-kernel@lists.infradead.org; Tue, 03 Jan 2023 11:09:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kFmJY+vslQxgxXBCJptuqK3BYSzEaZTWbCiEfuAfiTA=; b=0zrh56nKP3HIhetHZAVPsWWud9 Wc1rVNQuGF3MK6CWbAWjGhuxcTEBEPQHgexMYdnLoc9xvDigoWAgFqA1FhMsVbCbGpovrT11kjLQR L5VhnnvViJdCAshZGVWb/odO7mk5jPEWkWkEg5tFC1PO68TIC8Zt6QDCSOUlEH8uleoTX8Uuh0QUc LO0NOILhVeEAcUvDjQnntcZF5cYxCtFRZkdu65pseQU8oUBL0cTHObNG/7xb725VwJBSHMT3U5Lh0 g/twHenUC/2oD9bELMDHH6pVuV4iJX8xhIxjv54d47VyBBYjGdsmnHkxH07ZE72IAtoBawSTcxLFe u/k1nVpg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35920) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pCfAp-0005F5-GT; Tue, 03 Jan 2023 11:09:40 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pCfAm-00021J-In; Tue, 03 Jan 2023 11:09:36 +0000 Date: Tue, 3 Jan 2023 11:09:36 +0000 From: "Russell King (Oracle)" To: "Prof. Michael Taylor" Cc: linux-arm-kernel@lists.infradead.org Subject: Re: L_PTE_MT_BUFFERABLE / device ordered memory Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230103_030946_694935_56B30C34 X-CRM114-Status: GOOD ( 39.27 ) 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 Fri, Dec 30, 2022 at 02:23:40PM -0800, Prof. Michael Taylor wrote: > Hi, > > Apologies in advance if I have missed an ages old thread on this. And > apologies for the length of the description. > > I am trying to tune the memory mapped I/O performance of a ZYNQ 7000 > with an ARM A7 core running Linux. Reading this, I think there's a lot of confusion when I read this email. According to https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html, this is a Cortex-A9 core. I'm wondering what "ARM A7" above is referring to. I first wondered if it was referring to Cortex-A7, but that doesn't work out. Maybe you mean ARM architecture v7, which would make sense? > From what I can observe (in the > phys_mem_access_prot function in mmu.c), the default for a memory > range that has not been given in the device tree is "strongly > ordered" which means that the ZYNQ core will not proceed on to the > next such memory request until the previous one has fully completed. > This has very sub-optimal performance, requiring on average 24 cycle > per access overhead. I believe this corresponds to the setting > pgprot_noncached (and then to L_PTE_MT_UNCACHED) in the kernel. That is indeed what happens with phys_mem_access_prot() for memory areas that we don't know are emmory. > The > ARM architecture, however provides for another setting in the page > table entry of "device ordering", which maintains ordering and > quantity of requests going out to the device, without pausing the ARM > core. In various Xilinx forum posts, it has been confirmed that in the > baremetal OS option, that setting the value of the ARM page table TEX > and C B fields to 000, 0, 1 respectively, that the performance is > greatly improved (maybe 4 cycles per access). Unclear whether they are taking account of TEX remapping. > > Q1. My goal is to unlock this functionality in the Linux kernel. Any > best practices? > > (Below is what I tried/figured out.) > > Looking at the phys_mem_access_prot function, I therefore concluded > that perhaps I should map in the memory location using the device > tree, as reserved, and this would cause phys_mem_access_prot to select > pgprot_writecombine in the kernel. After doing this successfully, I > noticed a great improvement in performance, but also that only a small > fraction of transactions in my test case were actually making it out > to the I/O device. The test case was writing a series of zeros to the > same I/O address, which corresponds to a FIFO, so I really want to see > all of the zeros. Looking at the logic analyzer, I saw that the > processor was optimizing away the repeated zero writes, and that the > AWCACHE field on the AXI bus was set to 3. With TEX=0 and tex remapping enabled, we arrange for the C and B bits to have the same behaviour as previous architecture versions (because we need to) and this is the exact behaviour that older CPUs exhibit when using bufferable memory - writes are combined and repeated writes to the same location are optimised. > This was quite surprising > to me, as these fields suggest that the PTE is, per the ARM docs > (https://developer.arm.com/documentation/ihi0022/c/Additional-Control-Information/Cache-support), > cacheable and bufferable, rather than just bufferable. > > Diving deeper into the kernel, I see that in proc-macros.S, in > marv6_mt_table, This table isn't used for Cortex-A9. It is used for ARM architecture v6 processors that lack the TEX remapping facility, so we have to do our own table-based remapping. > the L_PTE_MT_BUFFERABLE entry is set to PTE_EXT_TEX(1) > (i.e TEX,C,B = 001,0,0) which per > https://developer.arm.com/documentation/ddi0406/c/System-Level-Architecture/Protected-Memory-System-Architecture--PMSA-/Memory-region-attributes/C--B--and-TEX-2-0--encodings > is listed as "Normal memory", but with out and inner regions given as > non-cacheable. I would have expected PTE_BUFFERABLE (i.e. > TEX,C,B=000,0,1). > > Also looking at proc-v7-2level.S, I see that BUFFERABLE is defined as > TR=10, IR=00, OR=00, where TR memory type (per > https://developer.arm.com/documentation/ddi0406/c/System-Level-Architecture/System-Control-Registers-in-a-VMSA-implementation/VMSA-System-control-registers-descriptions--in-register-order/PRRR--Primary-Region-Remap-Register--VMSA?lang=en) > is defined as 00=strongly-ordered, 01=device, 10=normal memory. So I > would have expected 01=device memory. This would give problems when there is a normal mapping of memory along side a device mapping - that is prohibited by the architecture. So we have to use TR=10 for this case. > Q2. What is the history behind using strong-ordering instead of > device-ordering for I/O writes? And why is the write-combining setting > mapping to "Normal Memory" rather than device memory? And why does > mmu.c not provide a mechanism for accessing device-ordering (or does > it)? It goes all the way back to ARM architectures v3..v5, where there was no TEX field, and the choices were: Uncached (CB=00) Bufferable (CB=01) Writethrough (CB=10) Writeback (CB=11) As previously mentioned, CB=01 merges writes, and even has some other funny behaviours when the same region is mapped in two different virtual address spaces - where writes bypass each other in non-program order. So the memory location ends up with a different value than is expected. Essentially on these devices. uncached is the only option for devices to ensure that devices see the same number of writes that the program issues. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel