[lkml]   [1998]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] scheduler patch, faster still
    Time for me to sound off on this very unproductive thread.

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.039 / U:14.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site