Re: [boost] Performance of various mutex implementations on Linux

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-24 06:14:39

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.