Re: 2.6.9-rc1-mm1

[Con Kolivas]

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

Attachment: signature.asc
Description: OpenPGP digital signature