Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > muc.lists.netbsd.source-changes > #156175
| From | Taylor R Campbell <riastradh@NetBSD.org> |
|---|---|
| Newsgroups | muc.lists.netbsd.source-changes |
| Subject | Re: CVS commit: src/sys/arch/arm/include |
| Date | 2026-06-08 14:13 +0000 |
| Organization | Newsgate at muc.de e.V. |
| Message-ID | <20260608141328.5B92B84D4B@mail.netbsd.org> (permalink) |
| References | <20260605080339.100BBFA2B@cvs.NetBSD.org> |
> Module Name: src > Committed By: skrll > Date: Fri Jun 5 08:03:38 UTC 2026 > > Modified Files: > src/sys/arch/arm/include: cpufunc.h > > Log Message: > arm: relax coherent DMA ordering barriers from DSB to DMB > > Use DMB instead of DSB for the ARM coherent DMA ordering macros dma_*_*() > > The previous definitions used DSB, which enforces completion semantics and > is heavier than needed for coherent device DMA ordering. DMB provides ordering > of memory operations without requiring full completion, making it the > appropriate barrier for these coherent-only CPU/device DMA paths. > > Tested on Fusion VM, Orion O6, and Thunderx. > > There is an approximate 1% performance improvement for the Fusion VM, but > less for Orion O6 and Thunderx. Thanks! I was preparing to commit this with the following message but you beat me to it. arm: Relax coherent case of bus_dmamap_sync to use DMB, not DSB. => DMB is needed to order memory operations with respect to other memory operations, such as filling an outgoing DMA buffer and writing to a doorbell register. We definitely need this. => DSB implies DMB, and is needed to order TLB and cache maintenance instructions with with respect to memory operations. But the coherent case is the case where we don't need to issue cache maintenance instructions. So there is no need to use DSB here, and I don't think there ever was one -- not even in earlier revisions of the architecture before some parts of the memory model were strengthened (when Arm decided to guarantee other-multicopy-atomicity, which is not relevant to DSB vs DMB). On some cores (e.g., Arm Cortex-A9 r4 Software Developers Errata Notice, ARM UAN 0009D ID32315, Erratum 794072: A short loop including a DMB instruction might cause a denial of service on another processor which executes a CP15 broadcast operation <https://documentation-service.arm.com/static/608118675e70d934bc69f143>) there are bugs requiring the use of DSB instead of DMB -- but that's a systemwide issue, not related to DMA I/O. And, without rewriting every instruction stream to replace DMB by DSB, it can _only_ be properly fixed by a CPU state bit causing DMB to act like DSB. If this causes issues, let's get them documented and justified! Because right now, there is no Arm documentation to my knowledge -- nor has there ever been -- justifying the use of DSB here. -- Posted automagically by a mail2news gateway at muc.de e.V. Please direct questions, flames, donations, etc. to news-admin@muc.de
Back to muc.lists.netbsd.source-changes | Previous | Next | Find similar | Unroll thread
Re: CVS commit: src/sys/arch/arm/include Taylor R Campbell <riastradh@NetBSD.org> - 2026-06-08 14:13 +0000
csiph-web