Re: [ck] Mainline plans

Re: [ck] Mainline plans

[Martin Steigerwald]

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

Am Donnerstag, 31. Mai 2007 03:38 schrieb Con Kolivas:
> On Tuesday 29 May 2007 21:30, Con Kolivas wrote:

> Again, as usual, I'm' frustrated. If cfs has yet to beat SD, why should
> mainline go with cfs? Ingo said to me offlist that the scheduler that
> performs the required task the best was what should go into mainline. I bet
> a million bucks that given Linus has given the go-ahead for cfs into
> mainline that he won't turn around and say "but wait, SD still has lots of
> case reports of better behaviour", so we should go with that. This is kinda
> funny I have to say. Ingo, I know you're reading, and no I don't believe
> there is evidence CFS is better in real world workloads yet. Sure, there's
> other issues of maintainability, code understanding and blah blah that
> you'll pull out as reasons cfs' superiority. Of course, performance is the
> ultimate judge, BUT as I said, I'm over it, mainline has caused me far too
> much pain anyway. .

Hi Con!

Maybe reports about scheduler tests and feedback should by default go to this 
mailing list *and* the kernel mailinglist.

I bet that Linus doesn't read this list and thus misses most of the favorable 
reports for SD.

I am using 2.6.21-ck2 everywhere now and I am really happy.

I did not test recent CFS, but Ingo asked me do to it with my Amarok machine, 
to test for regressions since introduction of increased 3D performance. In my 
last tests SD and CFS behaved quite equivalent to one another - that was with 
CFS-v11. If CFS-v14 has not regressed, it would work for me as well.

But I also appreciate the other enhancements in ck patchset and I would like 
to have as much as possible of it into mainline.

Actually I think the decision on which scheduler to put into mainline should 
depend on its technical merits and the user feedback.

Regards,
-- 
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]