> I doubt you have made any bechmarks about memory bus traffic during
> spin
(i have measured this, in user-space). We obviously have no bus traffic if
polling a variable and doing nothing else and the cacheline of the
variable is in shared mode - this is the case after you aquired the lock.
_Iff_ many processes are waiting for that spinlock to go inactive, then
there is bus traffic to all those CPUs - and only one of them 'wins', so
yes there are superfluous bus operations. The article appeared to imply
that spinning on a shared cacheline has performance implications - no it
doesnt have.
> > 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.
apparently they did have obvious contention problems not so long ago, SP5
fixed one of those. They had one big lock for all the networking driver
code. And there is one more data point, our file and pagecache locking is
more parallel than Microsoft's (at least according to benchmarks),
including NT5. But you are right, i cannot know for sure. The rest can be
decided whenever they put their code under the GPL ;)
> > 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).
yep. Actually there are techniques to patch the inlined spinlock code into
effective no-op operations, so i'd say this is not due to technical
reasons, but rather due to Microsoft's usual tactics to raise the cost of
entry (they want to make the driver API as Windows-dependent as possible).
-- mingo
-
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/