Hi Ben, On Thu, Apr 17, 2014 at 10:36:58PM +0100, Benjamin Herrenschmidt wrote: > On Thu, 2014-04-17 at 16:00 +0200, Peter Zijlstra wrote: > > > So the non-relaxed ops already imply the expensive I/O barrier (mmiowb?) > > and therefore, PPC can drop it from spin_unlock()? > > We play a trick. We set a per-cpu flag in writeX and test it in unlock > before doing the barrier. Still better than having the barrier in every > MMIO at this stage for us. > > Whether we want to change that with then new scheme ... we'll see. > > > Also, I read mmiowb() as MMIO-write-barrier(), what do we have to > > order/contain mmio-reads? > > > > I have _0_ experience with MMIO, so I've no idea if ordering/containing > > reads is silly or not. > > I will review the rest when I'm back from vacation (or maybe this > week-end). Did you get a chance to look at this? I've got a handful of Acks from other architectures, and there's a bug to fix in the x86 patch but it seems daft to send a v2 without talking about the fundamental rules of the accessors. Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
