I doubt you have made any bechmarks about memory bus traffic during spin
lock contention, and I'm pretty sure that Microsoft has made such
benchmarks. I think we should believe them that on x86, the memory
traffic during spin lock contention is a problem, even if you use normal
(ie non-locked) instructions. Before these queued spinlock were added(ie
WinNT 4), they used similar code as 2.3.18, except that they can't
inline spinlock calls. (I just left the kernel debugger)
> Windows NT apparently has problems with high
> contention spinlocks. So instead of reducing the number of spinlocks and
> reducing lock collisions, they decided to optimize the 'contention case'.
No. Microsoft has several hundert developers. They told one of them
"optimize the contention case", I don't think you can assume that NT has
a contention problem. I bet the contention of WinNT4 is lower than the
contention of 2.3.18.
> NT calls functions to aquire/release spinlocks, yuck!
Thats the price they must pay because the same driver must run on UP and
SMP computers without recompiling. This price is high, and it will rise
further if the differences between the slowest supported CPU
(486?Pentium) and the newest CPU become larger, but there is no way
around (for them).
-- Manfred
- 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/