lkml.org 
[lkml]   [2006]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory barriers and spin_unlock safety


On Sat, 4 Mar 2006, Benjamin Herrenschmidt wrote:
>
> The main problem I've had in the past with the ppc barriers is more a
> subtle thing in the spec that unfortunately was taken to the word by
> implementors, and is that the simple write barrier (eieio) will only
> order within the same storage space, that is will not order between
> cacheable and non-cacheable storage.

If so, a simple write barrier should be sufficient. That's exactly what
the x86 write barriers do too, ie stores to magic IO space are _not_
ordered wrt a normal [smp_]wmb() (or, as per how this thread started, a
spin_unlock()) at all.

On x86, we actually have this "CONFIG_X86_OOSTORE" configuration option
that gets enable for you select a WINCHIP device, because that allows a
weaker memory ordering for normal memory too, and that will end up using
an "sfence" instruction for store buffers. But it's not normally enabled.

So the eieio should be sufficient,then.

Of course, the x86 store buffers do tend to flush out stuff after a
certain cycle-delay too, so there may be drivers that technically are
buggy on x86, but where the store buffer in practice is small and flushes
out quickly enough that you'll never _see_ the bug.

> Actually, the ppc's full barrier (sync) will generate bus traffic, and I
> think in some case eieio barriers can propagate to the chipset to
> enforce ordering there too depending on some voodoo settings and wether
> the storage space is cacheable or not.

Well, the regular kernel ops definitely won't depend on that, since that's
not the case anywhere else.

Linus
-
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: 2009-11-18 23:46    [W:1.205 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site