Re: [PATCH] scheduler patch, faster still

Justin A. Kolodziej (4wg7kolodzie@vmsb.csd.mu.edu)
Tue, 29 Sep 1998 07:59:00 -0500


Rik van Riel wrote:
>
> On Mon, 28 Sep 1998, Justin A. Kolodziej wrote:
> > Steve VanDevender wrote:
> > >
> > > Oh please. Having read quite a bit of this debate, I'm much more
> > > supportive of Larry's point of view than Richard's.
> > As am I. Being one of the people who is IMHO one of the closest to
> > being Joe Blow User on this thread, I think that Mr. Gooch's results are
> > almost completely irrelevant to a plain old user. I cannot think of one
> > application that would be found in the typical office at present that
> > actually would need real-time scheduling.
>
> Just because you can't imagine the application that doesn't
> mean that Richard doesn't have one at hand :)
>

Ok, someone else provided an example for me (the Win-$@%#!^#$-printer).
If Richard could show that a page from Netscape prints in something like
2 minute 32 seconds on a Winprinter without his proposed change and
prints in only 1 minute 59 seconds with his change, that would be the
sort of proof I'm talking about. Same thing with compiling the
kernel... If he could show that the system remains more useable while
compiling the kernel with "make -j40 -l40" wiuth his change than
without, that would also be sufficient proof for me that his change
would be beneficial. Instead we get benchmark numbers for do-nothing
loops.

> Apart from that, I don't see any problems with visualizing
> such an app as well (or at least a normal RT app which got
> in trouble because of an overloaded rest-of-the-system).
>
> > Also, as far as I can tell it would take a major rewrite of the
> > scheduler to implement a second run queue.
>
> It wouldn't. It would involve copying a bit of existing code
> to make an RT path and then chainsawing the RT additions from
> the normal code path. It's an absolutely trivial change.
>

Sorry about that. I only use the kernel and report if something seems
broken (though I'm wrong half the time about that too! :) ). I don't
even pretend to know all these subtleties about how the thing works. Is
that grounds for dismissal from the list? I forget. :)

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

-- 
Easiest Color To Solve On A Rubik's Cube:
        Black.  Simply remove all the little colored stickers on the
cube, and each of side of the cube will now be the original color of
the plastic underneath -- black.  According to the instructions, this
means the puzzle is solved.
                -- Steve Rubenstein

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