On Mon, Nov 02, 2015 at 07:57:09PM +0000, Will Deacon wrote: > > >> smp_read_barrier_depends() is about a memory barrier where there is a > > >> data dependency between two accesses. The "depends" is very much about > > >> the data dependency, and very much about *nothing* else. > > > > > > Paul wasn't so sure, which I think is why smp_read_barrier_depends() > > > is already used in, for example, READ_ONCE_CTRL: > > > > > > http://lkml.kernel.org/r/20151007154003.gj3...@linux.vnet.ibm.com > > > > Quoting the alpha architecture manual is kind of pointless, when NO > > OTHER ARCHITECTURE OUT THERE guararantees that whole "read + > > conditional orders wrt subsequent writes" _either_. > > > > (Again, with the exception of x86, which has the sane "we honor causality") > > > > Alpha isn't special. And smp_read_barrier_depends() hasn't magically > > become something new. > > > > If people think that control dependency needs a memory barrier on > > alpha, then it damn well needs on on all other weakly ordered > > architectuers too, afaik. > > > > Either that "you cannot finalize a write unless all conditionals it > > depends on are finalized" is true or it is not. That argument has > > *never* been about some architecture-specific memory ordering model, > > as far as I know. > > You can imagine a (horribly broken) value-speculating architecture that > would permit this re-ordering, but then you'd have speculative stores > and thin-air values, which Alpha doesn't have.
I've tried arguing this point with Paul on a number of occasions, and I think he at one point constructed some elaborate scheme that depended on the split cache where this might require the full barrier. > > As to READ_ONCE_CTRL - two wrongs don't make a right. > > Sure, I just wanted to point out the precedence and related discussion. I purely followed 'convention' here. > > That smp_read_barrier_depends() there doesn't make any sense either. > > > > And finally, the alpha architecture manual actually does have the > > notion of "Dependence Constraint" (5.6.1.7) that talks about writes > > that depend on previous reads (where "depends" is explicitly spelled > > out to be about conditionals, write data _or_ write address). They are > > actually constrained on alpha too. > > In which case, it looks like we can remove the smp_read_barrier_depends > instances from all of the control-dependency macros, but I'll defer to > Paul in case he has some further insight. I assume you're ok with this > patch if the smp_read_barrier_depends() is removed? That would be good indeed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
