Erich Boleyn wrote in small part:
> protocol, but I'm pretty darn sure that only one processor is allowed
> to own a cache-line in the M or E states at any one time.
I believe it too. Table 9-3 [I'd post it if it wasn't mangled]
> 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.
> 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.
> For hardware devices, you have to use UC to make sure the actual bus
> cycles are the right ones, since the very act of doing a read or
> a write of a particular size, for example, might be recognized and
> used by a particular device.
No kidding. It seems like some 82443BX chips didn't like 16 bit
data reads (masking bit 0) and had to be read 32 bits.
-- Robert
-
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/