| |||||||||||||
Adaptive spinning futexesAdaptive spinning futexesPosted May 13, 2010 11:38 UTC (Thu) by farnz (guest, #17727)In reply to: Adaptive spinning futexes by etienne_lorrain@yahoo.fr Parent article: Adaptive spinning futexes
That gets into implementation dependent knowledge - on some implementations of hyperthreading, if one thread is just reading a memory location, testing the value, and looping, almost all the execution units will be spare for the other hyperthread. If that thread releases the lock quickly, the thread that has been spinning is instantly ready to work, and you get maximum benefits from hyperthreading.
(Log in to post comments)
Adaptive spinning futexes Posted May 13, 2010 14:13 UTC (Thu) by ejr (subscriber, #51652) [Link]
And in this situation the lock will be in L1 data cache, while the data *and* instructions needed for switching contexts will be in L2 at best, most likely in memory. Spinning within a shared cache is good for performance (not discussing energy, many other factors in play for that). Short locking times where the lock sits in shared cache with access times in the 10s of cycles call for spinning.
A problem with adaptive spinlocks occurs when you spin on something bounced between memory / caches / processors. By the time you swap out, you've eaten a large cost and blown a lot of memory traffic. I suspect the kernel's in a better position to know what's where with less cache overhead than user-space adaptive spinlocks, so this is sounding potentially great.
Adaptive spinning futexes Posted May 17, 2010 17:06 UTC (Mon) by dvhart (guest, #19636) [Link]
The second step here is to see about exposing the information only the kernel has currently to userspace. This provides userspace with the same advantage, and avoids the overhead of the syscalls. One tricky part is choosing where to put this data in memory. The other potential drawback here is that it may only work for process private futexes, so only threads of a single process could use it, while the kernel implementation works with threads and processes.
|
|||||||||||||