Re: [PATCH] scheduler patch, faster still

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 29 Sep 1998 21:17:00 +1000

Rik van Riel writes:
> On Tue, 29 Sep 1998, Richard Gooch wrote:
> > Rik van Riel writes:
> > > On Tue, 29 Sep 1998, Richard Gooch wrote:
> > >
> > > > - improves non-RT performance under all conditions
> > > My doubt is mainly between improvement and no improvement.
> > > Like Richard, I'm quite sure that there won't be any loss.
> >
> > The reason I say this is because SCHED_OTHER processes first have to
> > do some tests for policy != SCHED_OTHER before they can calculate
> > their goodness values. The patch I have in mind will avoid that,
> > yielding a small performance benefit.
> > I don't actually care too much about this small benefit (it will be
> > lost in the noise), I just want to emphasize that there is no
> > performance cost.
>
> OK, if you can show us a patch, you should be able to prove
> Larry & friends that your change is harmless.

Give me a moment :-) I'm working on it.

> If the patch is trivial enough, we can even push for inclusion.
>
> > Yep. Right now (2.1.123) has a bug with the way SCHED_YIELD is
> > handled: an RT process can end up yielding to a lower priority
> > process. That's contrary to the POSIX.4 spec.
>
> Aiee, I hadn't even seen this one... I have no clue
> how to fix this (except with gross inefficiencies)
> within the frame of the current system.
> To do that, we'd have to keep a list of RT processes on the queue,
> effectively reducing us to the separate-RT-runqueue option.
> QED.

Actually, I submitted a pretty simple patch Linus prior to 2.1.123
coming out, but I didn't hear anything. It's appended. I don't think
we need anything more complicated.

Regards,

Richard....

--- sched.c~ Sat Sep 5 02:13:29 1998
+++ sched.c Thu Sep 24 12:31:59 1998
@@ -272,6 +272,8 @@

if (policy & SCHED_YIELD) {
p->policy = policy & ~SCHED_YIELD;
+ if (p->policy != SCHED_OTHER)
+ return 1000 + p->rt_priority;
return 0;
}

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