On Tuesday, June 10, 2008 8:29 pm Nick Piggin wrote: > On Wednesday 11 June 2008 05:19, Jesse Barnes wrote: > > On Tuesday, June 10, 2008 12:05 pm Roland Dreier wrote: > > > > me too. That's the whole basis for readX_relaxed() and its cohorts: > > > > we make our weirdest machines (like altix) conform to the x86 norm. > > > > Then where it really kills us we introduce additional semantics to > > > > selected drivers that enable us to recover I/O speed on the abnormal > > > > platforms. > > > > > > Except as I pointed out before, Altix doesn't conform to the norm and > > > many (most?) drivers are missing mmiowb()s that are needed for Altix. > > > Just no one has plugged most devices into an Altix (or haven't stressed > > > the driver in a way that exposes problems of IO ordering between CPUs). > > > > > > It would be a great thing to use the powerpc trick of setting a flag > > > that is tested by spin_unlock()/mutex_unlock() and automatically doing > > > the mmiowb() if needed, and then killing off mmiowb() entirely. > > > > Yeah I think that's what Nick's guidelines would guarantee. And Jes is > > already working on the spin_unlock change you mentioned, so mmiowb() > > should be history soon (in name only, assuming Nick also introduces the > > I/O barriers he talked about for ordering the looser accessors it would > > still be there but would be called io_wmb or something). > > Exactly, yes. I guess everybody has had good intentions here, but > as noticed, what is lacking is coordination and documentation. > > You mention strong ordering WRT spin_unlock, which suggests that > you would prefer to take option #2 (the current powerpc one): io/io > is ordered and io is contained inside spinlocks, but io/cacheable > in general is not ordered. I was thinking it would be good for the weaker accessors, but now that I think about it you could just use the new io_* barrier functions. I didn't mean to imply that I wasn't in favor of the io/cacheable ordering as well. > For any high performance drivers that are well maintained (ie. the > ones where slowdown might be noticed), everyone should have a pretty > good handle on memory ordering requirements, so it shouldn't take > long to go through and convert them to relaxed accessors. Yep. Thanks for working on this, Nick, it's definitely a good thing that you're taking control of it. :) Thanks, Jesse -- 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
