Boost logo

Boost :

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.
> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at