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@hub.org secondary: scrappy@{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@illustra.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.

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 :)

Yep, I like it.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

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@hub.org secondary: scrappy@{freebsd|postgresql}.org

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

Hard to beat the backoff argument. I vote we only use select().

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Sat, 21 Mar 1998, Bruce Momjian wrote:

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

Hard to beat the backoff argument. I vote we only use select().

I haven't heard any compelling arguments so far as to why
sched_yield() is better then select(), so I tend to vote the same way...

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