Messages in this thread | | | Date | Wed, 8 May 2002 08:57:52 +1000 | From | Anton Blanchard <> | Subject | Re: Memory Barrier Definitions |
| |
> 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?
Anton - 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/
| |