Re: [HACKERS] Re: sched_yield()

> On Sun, 22 Mar 1998, Mattias Kregert wrote:
>
> > The Hermit Hacker wrote:
> > >
> > > What's the possibility of doing this similar to how we do some of
> > > the other functions (dl_open comes immediately to mind)...make a
> > > pg_sched_yield function and use that, which is built based on the various
> > > platforms?
> > >
> > > Right now, I don't believe we have *anything* in place, so have
> > > pg_sched_yield() return 0 (or an equivalent) for every platform except for
> > > Linux...
> >
> > But sched_yield() is not Linux-specific:
> > -- The sched_yield() function relinquishes the processor for the
> > -- running process.
> > -- IEEE Std 1003.1b-1993, 13.3.5. (POSIX real-time standard 1003.lb)
> >
> > Except from Linux, I can find references to sched_yield() in LynxOS,
> > DECthreads thread library, AIX 4.1 and up (libc), Solaris (thread.h
> > (c)1994 Sun
> > Microsystems), Unix98, GNU, C EXECUTIVE(r) and PSX(tm) real time kernels
> > ...
> > This is just a quick search.
> >
> > Perhaps we should enable sched_yield() for every OS except for... well,
> > what's the
> > name of that OS which does not have sched_yield()... FreeBSD ;)
> >
> > After all, sched_yield() is five years old. Any reasonable OS should
> > have it.
>
> You missed my point...so far as I've heard, there are two ways of
> doing what is being proposed...either using sched_yield() on those systems
> that support it, or select() on those that don't. If you are going to
> build a patch for this, it should look something like:
>
> #ifdef HAVE_SCHED_YIELD
> <insert sched_yield() code here>
> #else
> <insert select() code here>
> #endif
>
> Totally 'configure' configurable, and non-system dependent :)
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
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.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- I realize now that irony has no place in business communications.