On Sat, Oct 18, 2008 at 12:44:05PM -0600, Matthew Wilcox wrote: > On Sat, Oct 18, 2008 at 10:00:30AM -0700, Linus Torvalds wrote: > > > Apparently pairwise ordering is more interesting than just a theoretical > > > thing, and not just restricted to Alpha's funny caches. > > > > Nobody does just pairwise ordering, afaik. It's an insane model. Everybody > > does some form of transitive ordering. > > I assume you're talking about CPUs in particular here, and I don't know > of any counterexamples. Yes, just CPUs. > If you're talking about PCI devices, the model is not transitive. > Here's the exact text from Appendix E of PCI 3.0: > > A system may have multiple Producer-Consumer pairs operating > simultaneously, with different data - flag-status sets located all > around the system. But since only one Producer can write to a single > data-flag set, there are no ordering requirements between different > masters. Writes from one master on one bus may occur in one order on > one bus, with respect to another master's writes, and occur in another > order on another bus. In this case, the rules allow for some writes > to be rearranged; for example, an agent on Bus 1 may see Transaction > A from a master on Bus 1 complete first, followed by Transaction B > from another master on Bus 0. An agent on Bus 0 may see Transaction > B complete first followed by Transaction A. Even though the actual > transactions complete in a different order, this causes no problem > since the different masters must be addressing different data-flag sets. > > I seem to remember earlier versions of the spec having more clear > language about A happening before B and B happening before C didn't > mean that A happened before C from the perspective of a third device, > but I can't find it right now. > > Anyway, as the spec says, you're not supposed to use PCI like that, > so it doesn't matter. Interesting. Hopefully as you say it won't matter. -- 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
