lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.9-rc1-mm1
    Andrew Morton wrote:
    >
    > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm1/
    >
    >
    > - nicksched is still here. There has been very little feedback, except that
    > it seems to slow some workloads on NUMA.

    That's because most people aren't interested in a new cpu scheduler for
    2.6. The current one works well enough in most situations and people
    aren't trying -mm to fix their interactive problems since they are few
    and far between. The only reports about adverse behaviour with 2.6 we
    track down to "It behaves differently to what I expect" or applications
    with no (b)locking between threads suck under load. Personally I think
    the latter is a good thing as it encourages better coding, and the
    former is something we'll have with any alternate design.

    The only feedback we got on staircase was that it helped NUMA somewhat
    and Nick and Ingo made some criticisms (not counting any benchmarks I
    had to offer). The only feedback on nickshed was that it hurt NUMA
    somewhat, SMT interactivity was broken (an easy enough oversight), and I
    did not comment to avoid giving biased criticism.

    If you're after subjective performance feedback you're less likely to
    get it now than ever since you've made a strong stance against
    subjective reports, due to placebo effect. LKML is scary enough for the
    average user already. We have a situation now that if one brave single
    user reports good or bad behaviour everyone runs off that one user's
    report. Ouch!

    There isn't going to be a 2.7 any time soon and there are people that
    are using alternate schedulers already in production; which is obviously
    why you're giving them a test run in -mm. Clearly the lack of a formal
    (2.7) development branch makes this even harder. Your attempt at
    preventing "good stuff' from rotting in alternate trees when mainline
    should be benefitting is admirable. While it's fun to rewrite the
    scheduler and gives us something to play with, the current level of
    feedback is hardly the testbase off which to replace it unless there's
    something strikingly better about a new cpu scheduler.

    It will be interesting to see if this spawns any further discussion or
    whether Peter's scheduler's performance will also be lost in a low
    signal to noise ratio when it gets a run in -mm.

    Cheers,
    Con
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.022 / U:0.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site