[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.9-rc1-mm1
    On Thursday 26 of August 2004 13:07, Con Kolivas wrote:
    > Andrew Morton wrote:
    > >
    > >.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.

    I am, but I have no benchmarks that give any useful numbers.

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

    Actually, with the current scheduler, updatedb really sucks. It's supposed to
    be a background task, but it hogs IO resources and memory like crazy
    (disclaimer: it's my personal subjective observation).

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

    Frankly, if I had any useful benchmark, I would have readily run it and posted
    the results. The problem is that I don't know what kind of results you are
    interested in. Please let me know what _exactly_ you want to measure.
    Please propose some benchmarks or post a HOWTO, or what. "Help me help you".

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

    I think the problem is that relatively not so many people run -mm, and even
    less people try to use them for a longer time. Also, there sometimes are
    some issues with -mm that must be sorted out first, but then there's not much
    time left for testing the scheduler before the next -mm.


    For a successful technology, reality must take precedence over public
    relations, for nature cannot be fooled.
    -- Richard P. Feynman
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.025 / U:76.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site