Messages in this thread | | | Date | Sat, 27 Nov 1999 21:18:43 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Thu, 25 Nov 1999, Andrea Arcangeli wrote:
> 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/
| |