User: Password:
|
|
Subscribe / Log in / New account

Preventing overly-optimistic spinning

Preventing overly-optimistic spinning

Posted Aug 26, 2010 15:12 UTC (Thu) by PaulMcKenney (subscriber, #9624)
In reply to: Preventing overly-optimistic spinning by liljencrantz
Parent article: Preventing overly-optimistic spinning

Hard to say. The usual way to see that many threads are spinning is for these threads to write (using atomic instructions) to the lock word, which would result in more cache thrashing, and would delay the lock release. This usually slows things down rather than speeding them up.

But you can always give it a try and see what happens.


(Log in to post comments)

Preventing overly-optimistic spinning

Posted Aug 26, 2010 16:10 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

I guess it would depend on the cache protocol too, wouldn't it?

In a MESI, you would end up bouncing lines (S => M transition on the first writer, S => I on the others, followed by M => S and I => S). An ESI system (write through caches w/ no notion of "modified"), you'd get something similar.

In a MOESI such as Athlon's, I believe you minimize the cost. The first writer does an S => O and broadcasts the write to everyone else that's in S.

From that, I'd say it's rather important to measure on multiple architectures, since the tradeoffs will vary.

Preventing overly-optimistic spinning

Posted Aug 26, 2010 16:25 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]

I agree with your MESI assessment, but would want to see test results for the MOESI case -- there would be added traffic from the broadcasts. Which is all to say that I very much agree with you about the importance of testing on multiple architectures!


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds