Re: [HACKERS] Re: sched_yield()

On Sat, 21 Mar 1998, David Gould wrote:

> Ok, I will add a configuration option
>
> USE_SCHED_YIELD
>
> to the select patch I am working on. This can be enabled by configure.
> Assuming someone can find the header files needed on all the platforms.
>
> However, we should not assume that sched_yield() even where available is
> the automatic "right thing". It might be, but...
>
> The situation that either the select() or the sched_yield() style of
> spinlock back off is meant to help is when there are a number of processes
> busywaiting on the same spinlock.
>
> On Linux, sched_yield() triggers the scheduler to to a full priority re-calc
> for all processses. This is slightly expensive especially with a long run
> queue. Having a bunch of processes pound on sched_yield() might be actually
> worse than to use select(). At the very least it needs testing.
>
> Secondly, the select() backoff patch I am working on starts out with a zero
> timeout and backs off incrementally by increasing the timeout value on
> subsequent iterations. The idea is to break up convoys and avoid big piles of
> processes pounding on a spinlock. This cannot be done with sched_yield().
>
> Which is better? Well, golly gosh, I have no idea. I know that the select()
> flavor effectively solves the problem caused by hard loop busy waiting.
> Without some testing it is kinda hard to say more than that. I will try to
> fit in some testing, but if someone has a favorite many process workload
> and would like to try comparing both flavors it would be useful.

Okay, we have two differing viewpoints here...from what I've been
able to read, the select() solution will work on *all* platforms, while
the sched_yield() will work on *some* systems, but not all.

I personally like the "work on all platform" solution, but that's
just me :)

I may have missed it, but I'm curious as to under what
circumstance sched_yield() is better then the select() solution? The
"con", as I see it, is that sched_yield() doesn't work everywhere...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org