...
> > First of all, for the LOCK to only go as far as the cache, then
> > the line must be in a either of the M or E states. If it is in
> > an S state, it must get into one of the M or E states first.
>
> Agreed as well per 9-3. But if you write to an S line, it becomes E.
Sure, but the point is that, before the write or LOCK can take place,
it has to do a Read-For-Ownership to the bus first, which, if successful,
puts it into the new state. It doesn't just assume it can willy-nilly
change the line into that state. That would be bad.
...
> > The WB memory type is very definitely the one you want to use. It
> > is coherent, just not from the perspective of hardware devices
> > on the bus. Using WT or UC would add complexity (since you have to
> > set it up), and simply lose you performance.
>
> Agreed WT/UC loses performance, but maybe not much if only accessed
> via spinlocks with their LOCK semantics. For normal DRAM it's terrible!
>
> My vision is a single 4kB kernel WT/UC page dedicated to spinlocks.
> Setup isn't difficult, but administering the addresses might be.
> Users would be on their own with WB spinlocks, or maybe the
> kernel could serve one.
<shrug>
I suppose you can do that if you want, but my point is that it is:
a) More coding work/complexity, b) slower, and c) buys you nothing if
you use the right locked instructions anyway.
If you wanted to re-write the code to make UC locks with no locked
instructions, then I think there is a way to make it work, but it's
terribly slow and inefficient to code it to work that way...
probably even slower than using locked instructions with UC.
No other SMP OS I know of uses them on IA32, either. Why pay all that
if you don't have to?
Erich Boleyn
PMD IA32 Architecture
Intel
-- Erich Boleyn PMD Architecture <esboleyn@ichips.intel.com>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/