On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote: > On Wed, 28 Mar 2018 11:55:09 -0400 (EDT) > David Miller <davem@xxxxxxxxxxxxx> wrote: > > > From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> > > Date: Thu, 29 Mar 2018 02:13:16 +1100 > > > > > Let's fix all archs, it's way easier than fixing all drivers. Half of > > > the archs are unused or dead anyway. > > > > Agreed. > > While we're making decrees here, can we do something about mmiowb? > The semantics are basically indecipherable. I was going to tackle that next :-) > This is a variation on the mandatory write barrier that causes writes to weakly > ordered I/O regions to be partially ordered. Its effects may go beyond the > CPU->Hardware interface and actually affect the hardware at some level. > > How can a driver writer possibly get that right? > > IIRC it was added for some big ia64 system that was really expensive > to implement the proper wmb() semantics on. So wmb() semantics were > quietly downgraded, then the subsequently broken drivers they cared > about were fixed by adding the stronger mmiowb(). > > What should have happened was wmb and writel remained correct, sane, and > expensive, and they add an mmio_wmb() to order MMIO stores made by the > writel_relaxed accessors, then use that to speed up the few drivers they > care about. > > Now that ia64 doesn't matter too much, can we deprecate mmiowb and just > make wmb ordering talk about stores to the device, not to some > intermediate stage of the interconnect where it can be subsequently > reordered wrt the device? Drivers can be converted back to using wmb > or writel gradually. I was under the impression that mmiowb was specifically about ordering writel's with a subsequent spin_unlock, without it, MMIOs from different CPUs (within the same lock) would still arrive OO. If that's indeed the case, I would suggest ia64 switches to a similar per-cpu flag trick powerpc uses. Cheers, Ben. > Thanks, > Nick -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
