Steve VanDevender wrote:
>
> Kurt Garloff writes:
> > On Mon, Sep 28, 1998 at 01:32:42AM -0600, Larry McVoy wrote:
> > > ...
> >
> > Sorry, Larry, I think you know very well what you are talking about, but
> > your style of saying it gives everybody the impression that you are in love
> > with the current scheduler code and everybody who suggest changes is hurting
> > your feelings. So your answers are really not very nice to read.
>
> 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.
Also, as far as I can tell it would take a major rewrite of the
scheduler to implement a second run queue. A nice project for version
2.3. or even 3.0, depending on how long it takes for Mr. Gooch to
provide some kind of proof that the impact would be noticable in
real-time applications, or running RTLinux, or whatever the change is
supposed to impact.
> Richard believes that there is some source of variance in latency
> in scheduling that he cannot explain, that he claims is affecting
> the performance of an unspecified "real-time" application without
> explanation and without explaining the "real-time" requirements
> of that application, and is proposing to modify the scheduler
> based on these very vague observations.
>
> Larry's position is consistently that if the source of variance
> in scheduling cannot be explained (or even duplicated by other
> benchmarks), there is no reason to change the scheduler based
> purely on such vague observations. For some reason Richard is
> taking this way too personally.
I would tend to agree with Larry here. I don't really even find that
much variance in Richard's benchmark on my system. For example:
Running his benchmark 10 times in a row with no processes under X with
Netscape up and running I got: 7, 11, 11, 11, 11, 11, 11, 11, 11, 11 us.
Running it, same configuration, 10 processes: 9, 9, 12, 12, 10, 9, 9, 9,
12, 10 us.
What variance were you talking about? The spread between maximum and
minimum? That is usually a bad categorizaton of the data. Standard
deviation gives 1.26 for no processes and 1.37 for 10. And yet a
standard deviation doesn't seem to fit at all; the distribution seems
double-peaked, and my limited knowledge of stats doesn't allow me to
analyze that.
Sure, I'm in favor of progress, but unless the benefits are clear, I
also prefer to go by "If it ain't broke, don't fix it" unless there is a
compelling reason to, which in this case has not been demonstrated.
Justin A. Kolodziej
--
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/