Messages in this thread | | | Date | Fri, 3 Mar 2006 14:04:21 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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/
| |