Re: SCHED_YIELD again

Richard Gooch (rgooch@ras.ucalgary.ca)
Sat, 9 Oct 1999 18:13:09 -0600

Borislav Deianov writes:
> On Sat, Oct 09, 1999 at 05:46:39PM -0600, Richard Gooch wrote:
> > Borislav Deianov writes:
> > > As has been pointed out before, sched_yield currently doesn't work
> > > for SCHED_RR processes. There was a patch to fix this about two
> > > months ago by Artur Skawina but, as far as I can tell, it was
> > > ignored (probably because it included the controversial SCHED_IDLE
> > > support). So I'm having another go.
> >
> > IIRC, that patch was to force a SCHED_RR (or SCHED_FIFO) process to
> > give up the CPU if it calls sched_yield(), and allow a SCHED_OTHER
> > process to run.
>
> I think this is not the case. Here is a link to his patch:
> http://www.deja.com/getdoc.xp?AN=507504549&fmt=text
>
> > If this is the same patch, then it should be rejected. The premise is
>
> This is not the same patch.

Agreed. But in your patch I saw some that appears to re-introduce a
bug I fixed some time ago. You were unconditionally setting
SCHED_YIELD in sched_yield(). I made it conditional in the first place
because POSIX.4 semantics were not being obeyed.

> > flawed. POSIX.4 states that RT processes will always run in preference
> > to SCHED_OTHER. A RT process which does sched_yield() *should not*
> > give up it's CPU to a SCHED_OTHER process.
>
> Agreed. With my patch a RT process will only yield to another RT
> process with the same or higher priority.

Are you positive? Can you send me the patch privately again (sorry, I
deleted it once I saw the bit I was worried about).

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/