On Thu, Aug 23, 2007 at 06:27:42PM +0200, Benjamin Herrenschmidt wrote: > On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote: > > > > On Thu, 23 Aug 2007, Nick Piggin wrote: > > > > > > Also, FWIW, there are some advantages of deferring the mmiowb thingy > > > until the point of unlock. > > > > And that is exactly what ppc64 does. > > > > But you're missing a big point: for 99.9% of all hardware, mmiowb() is a > > total no-op. So when you talk about "advantages", you're not talking about > > any *real* advantage, are you? > > I wonder whether it might be worth removing mmiowb and having all archs > that matter do like ppc64 though... It's just yet another confusing > barrier that most driver writers get wrong..
Only sn2 and powerpc really matter, actually (for different reasons). All smp architectures other than powerpc appear to have barrier instructions that order all memory operations, so IOs never leak out of locking primitives. This is why powerpc wants a wmb (not mmiowb) before spin_unlock to order IOs (pity about other locking primitives). And all platforms other than sn2 don't appear to reorder IOs after they leave the CPU, so only sn2 needs to do the mmiowb thing before spin_unlock. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
