[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.180 / U:4.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site