Re: 2.6.9-rc1-mm1

Con Kolivas
2004-08-26T11:14:49Z

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]