On Mon, 2018-04-09 at 17:03 +0200, Peter Zijlstra wrote: > On Mon, Apr 09, 2018 at 07:45:22AM -0700, James Bottomley wrote: > > > https://parisc.wiki.kernel.org/images-parisc/7/73/Parisc2.0.pdf > > > > > > I don't see the U-bit mentioned in the below blurb, and also, I > > > see no mention on why SYNCDMA is not needed. > > > > Um, well U is uncached and is used mostly for memory based IO > > regions. We also have the odd system that doesn't have the U bit, > > which is why there's a network and a scsi driver with > > dma_cache_sync() in them. > > > > The point here is that U being caching is nothing to do with > > ordering. > > So I clearly had my reading skills disabled this morning (this wasn't > the only such occurence). In appending G, Memory Ordering Model, it > states that U=1 results in strongly ordered stuff, and for some > reason I read it as being required. But you're right, it's just one > of many possible cases. > > The O-bit is indeed what we should be looking at. > > > > A paranoid me would do mb() as SYNCDMA and __smp_mb() as SYNC, > > > given that the manual also states it NO-OPs these instructions > > > when not needed. > > > > I think you misunderstand how ordering and caching work. Ordering > > is the province of barriers and we insert the ordering into the > > code assuming we're in the CPU domain (usually everything as seen > > by the cpus is fully cache coherent on parisc). Caching is the > > province of the coherence domains (usually CPU to bus) and we > > handle that in the dma_ IO operations. > > > > So we can quibble about whether we need a syncdma in our dma_ > > operations, we'd never need one in the execution barriers. > > I was under the impression that mb() should (also) order against DMA > and MMIO things, while smp_mb() is just for the SMP/CPU domain. I really don't think so. A lot of PCI NUMA systems (following on from the old SGI altix) want relaxed ordering on the PCI bus because strong ordering is really costly. I haven't been following recently although I was involved initially but I think we've moved from the old io_mb to the read/writeX_relaxed() for this instead with the non _relaxed variants incorporating the DMA barrier. The point being we wouldn't want mb() slinging hugely expensive IO ordering instructions into the system. If someone wants to pay that cost, they want to be doing it explicitly. > Also note how with asm-generic/barrier.h the dma_*mb() things default > to being mb(). For PA, I don't actually think the syncdma is anything other than a nop, but if it were necessary, we'd need it only in the dma barriers. James > -- > To unsubscribe from this list: send the line "unsubscribe linux- > parisc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
