Re: [PATCH] scheduler patch, faster still

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Tue, 29 Sep 1998 13:04:34 +0200 (CEST)

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.

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.

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

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