Messages in this thread | | | Subject | Re: Opinion on ordering of writel vs. stores to RAM | From | Benjamin Herrenschmidt <> | Date | Mon, 11 Sep 2006 13:53:37 +1000 |
| |
On Mon, 2006-09-11 at 03:48 +0200, Segher Boessenkool wrote:
> > Ordering between stores issued by different CPUs has no meaning > > whatsoever unless you have locks. That is you have some kind of > > synchronisation primitive between the 2 CPUs. > > And that's exactly what mmiowb() does right now -- it makes sure > the I/O ends up at some I/O hub that will keep the accesses in > order, before it allows the current CPU to continue.
No. mmiowb isn't itself a synchronisation primitive between CPUs. It's a barrier. The lock enclosing the MMIOs is the synchronisation primitive. mmiowb() makes it actually work with MMIOs since otherwise, MMIO stores might "leak" out of the lock.
There is no concept of ordering between a flow of stores from 2 CPUs. There is no "before" or "after" (or rather, they aren't defined) unless you create a common "t0" reference, in which case you can indeed say wether a given store on a given side is before or after this "t0".
This common reference can only excist if code on -both- sides actually implement it, that is, it has to appear somewhere in the program to have any meaning.
mmiowb() doesn't do that. The spinlock does. That's the referene. That's what crates a concept of "before" and "after" (or rather "inside" or "outside"). mmiowb() is merely an implementation detail to make this actually work when MMIOs are involved.
> Aaaaaaaanyway... the question of what to call mmiowb() and what its > exact semantics would become, is a bit of a side issue right now, let's > discuss it later...
See my proposed document with explicit semantics.
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |