Hi Paul, Paul Baxter wrote:
My (limited) understanding from recent linux kernel mailing list discussions regarding supposed regressions in the scheduler is that sched_yield does not have a well-defined behaviour for anything other than SCHED_FIFO tasks and as such its implementation and performance may vary greatly depending on a particular scheduler implementation.
Yes, undoubtedly. I would not suggest using a yield-based lock if you expect that it will actually be contended more than a very small proportion of the time. (Unless perhaps the total number of threads/processes in the system is small).
The recent regression noted for a network benchmark called iperf, used sched_yield and saw major changes to performance. http://lkml.org/lkml/2007/10/1/279 might be a start
And interestingly it was on an ARM system (a NAS box), where moving from yield to pthreads might not help much if my analysis is accurate! The fix that was suggested removed the need for the lock altogether, if I understand it correctly.
The advice was not to rely on sched_yield other than in simple 'don't care' apps. (and that iperf wasn't
Perhaps try your sched_yield tests on most recent kernel and play with the different scheduler sched_yield strategies to see if that influences your non-contended/contended settings. Probably shouldn't end up relying on it anyway so the point may be moot...
There are too many different access patterns for me to investigate them all, so I'm not going to make any claims except for the non-contended case. I keep hoping that someone has already written a benchmark suite for studying this sort of thing. The important thing is that my futex code will have the same algorithmic behaviour as pthreads in all cases, but with better performance, and I suggest using it for applications where the probability of contention is measurable. Regards, Phil.