Messages in this thread | | | Date | Mon, 13 May 2002 11:16:52 -0700 | From | Jesse Barnes <> | Subject | Re: Memory Barrier Definitions |
| |
On Wed, May 08, 2002 at 08:57:52AM +1000, Anton Blanchard wrote: > > > You have > > > > Compiler ordering > > CPU v CPU memory ordering > > CPU v I/O memory ordering > > I/O v I/O memory ordering > > Yep. Maybe we could have: > > CPU v CPU smp_*mb or cpu_*mb > CPU v I/O *mb > I/O v I/O io_*mb > > Then again before Linus hits me on the head for hoarding vowels, > > http://hypermail.spyroid.com/linux-kernel/archived/2001/week41/1270.html > > I should suggest we make these a little less cryptic: > > CPU v CPU cpu_{read,write,memory}_barrier > CPU v I/O {read,write,memory}_barrier > I/O v I/O io_{read,write,memory}_barrier > > > and our current heirarchy is a little bit more squashed than that. I'd > > agree. We actually hit a corner case of this on the IDT winchip x86 where > > we run relaxed store ordering and have to define wmb() as a locked add of > > zero to the top of stack - which does have a penalty that isnt needed > > for CPU ordering. > > > > How much of this impacts Mips64 ? > > I remember some ia64 implementations have issues. Jesse, could you > fill us in again? I think you have problems with out of order > loads/stores to noncacheable space, right?
Both MIPS64 and our NUMA IA64 implementation have weakly ordered I/O. The primitives outlined above should be sufficient to order I/O and memory references on both platforms without unnecessary penalties. Thanks for adding me to the Cc: list, sorry it took me so long to respond.
It might also be good to summarize the ordering issues in a document in the Documentation directory. I've got a little something started (see the ia64 patch for 2.5) for I/O ordering, and I have another document that covers CPU memory ordering too that I could probably contribute.
Thanks, Jesse - 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/
| |