> On Thu, 25 Nov 1999, Gerard Roudier wrote:
>
> >happenned and may-be Linux would never have been broken for SMP locks.
>
> It's not broken. It's only too much clever ;).
Sure it was broken for the reason that 'not optimal' means 'highly broken'
under Linux. :-)
By the way, I am not that impressed about the result:
1) Either we use a lock prefix and latency in case of contention is
deterministic but the cost is about 20 cyles (the cache will be aware
of the STORE and will raise HITM if another CPU wants the data).
2) Or we have to cross fingers for the CPU to drain the STORE out of
the write buffer fast enough, but the cost is just a couple of cycles.
Under situation (2), let me write some user code that writes a single
location and then loops reading it. In case of contention on a spinlock,
it may well sometimes happen that some other CPUs (31?) be stalled until
some external event does happen. ;-)
To be serious, I didn't read anything about how short a STORE is
guaranteed to be drained to the cache (or memory). Does this mechanism
only rely on trashing ?
Still joking :), if it is so it may work a lot better under NT than under
Linux.
Gérard.
-
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/