lkml.org 
[lkml]   [2002]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.114 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site