Re:Measuring mutexes, spinlocks and how bad the Linux schedu...
by ketzu on Wednesday January 01, 2020 @07:04AM
(#21927719)
I believe the supposed beneficial case of blocking vs spinning can't be captured well by those categories, as it's "contended, but not for long" and "contended, but for longer".
That's the reason for the "may have a bit of capped spinning before waiting in the scheduler".
[ Parent
| on HN ]
Re:Measuring mutexes, spinlocks and how bad the Linux schedu...
by p0nce on Wednesday January 01, 2020 @07:53AM
(#21927840)
Honestly I'm not so sure about the case for spinning; in x264 source you can see CRITICAL_SECTION is tuned to have a spincount of 0. This is a very optimized, multi-threaded app. They didnt want any spinning.
https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c1457...
In my own attempts I've been unable to measure the impact of the spinlock count, and took spincount = 40 like in https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/... ...who also took measurement from elsewhere. The default is 4000 on Windows!
I don't argue spinning isn't valuable ; what I say is that it's necessarily never the bottleneck (else your task size really is too small).
After all, if you spend all your time in synchronization, that means you probably need to have bigger tasks, not more clever synchronization primitives.