Am Sonntag 10 Juni 2007 schrieb Linus Torvalds:
Hi Linus!
> Ehh.. It was tested extensively by lots of people. It was in -mm for a
> while, and yes, there have been tons of people testing both. I've
> followed it, and it seems fair to say that yes, Ingo took a lot of
> ideas from SD, but CFS seems to have gotten more people involved, and
> we had several people compare the two, and CFS was generally better.
Well actually I did not see that general result yet. I have seen quite
some testings and quite some reports on the ck patch mailinglist also
where in favor of SD. If it matters I will collect those, but I think
Ingo already did include most of them in his summary.
Ingo's own mail collecting feedback results does not indicate any favorite
yet[1]:
" Thibaut Varene: ...
Serge Belyshev: ...
Tobias Gerschner: about equal (-v?)
Michael Gerdau: about equal (-v13)
Vytautas Stankevicius: CFS not as interactive (-v?)
Markus Trnqvist: ...
"brihall": ...
Diego M. Vadell: ...
Cory Grunden: about equal (-v15)
Vincent Fortier: about equal (-v14)
Jason F. McBrayer: CFS not as interactive (-v8)
Maciej Soltysiak: ...
Michael Chang: ...
Matthew Hawkins: CFS audio stuttering (-v11)
Martin Steigerwald: about equal (-v11)"
http://bhhdoa.org.au/pipermail/ck/2007-June/007794.html
According to Ingo most of the interactivity issues should be fixed by now.
Still I do not see how that translates to "CFS was generally better".
What I read from recent feedbacks last mails is: They are generally on par
while there are still reports that one or the other performs better in
some area:
- possibly a new CFS regression:
http://bhhdoa.org.au/pipermail/ck/2007-June/007871.html
- stable / more fair massive_intr results?:
http://bhhdoa.org.au/pipermail/ck/2007-June/007878.html
> That's how open source works.
How it should work and can only work if feedback is collected before
summarizing it! IMHO you came to the "CFS was generally better"
assumption to early. In my perception a general result in favor of one of
the schedulers is *not yet there*!
> Does maintainership matter? Of course it does. Ingo has effectively
> been the maintainer of the scheduler for the last five years or so. So
> his code and words tends to weigh more heavily. AS IT SHOULD.
Agreed. Also it is important on how good a developer is able to support
his addition. Both developers did their best to fix bug reports and
issues. To me it seems that Ingo has a bit more time, manpower - partly
due to the health issues of Con - to spare.
> But in the end, technology is what matters. Several of the benchmarks
> showed that CFS does really really well in the fairness area.
Such as? Really well as in "better as SD"?
> So yes, everybody is biased. That's a fact of life. Anybody who tells
> you he is totally unbiased is lying.
Yes, exactly.
Yet, in my perception even those biased oppinions to not yet tend to favor
*one* of the schedulers. And as someone to decide on which scheduler to
include you should really collect the available feedback *before*
summarizing it. And honestly I do not think you did a good job on that.
> But we do try to make decisions on
> technical grounds, and right now CFS seems to be winning.
Actually I do not yet see this (see above). Could be that I am missing the
reports you indirectly refer to.
> A big issue for me is also the difference in how Con and Ingo took
> criticism. Both SD and CFS were criticized by various people over
> different things, and quite frankly, Ingo ended up trying to figure out
> why something didn't work, while Con ended up getting involved more in
> flame-wars with the people who criticised SD.
>
> Is that important too? Yes it is.
My perception is differently here too. As far as I read and saw Con worked
upto his personal limits and likely beyond them in order to fix bugs and
issues.
As I seen he reacted frustrated when it seemed to him that the decision on
which scheduler is to go into the kernel has already been made. Which
IMHO is quite understandable. Whether his perception of the decision
already made matches yours or that of Ingo is a different question tough.
> And yes, apparently Con was sick for part of the time, and that
> certainly didn't help, but in the end, right now it looks like Con
> should take a lot of pride in having shown where the current scheduler
> has problems, and convinced Ingo to fix them - somewhat differently
> than Con did, but the thing that matters is whether the end result is
> better, not who or how it got there.
True of course.
At least in my subjective testing I can't tell any difference anymore, so
it boils down to design criteria, code size, ability to maintain...
[1] http://bhhdoa.org.au/pipermail/ck/2007-June/007794.html
Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Am Dienstag 12 Juni 2007 schrieb Martin Steigerwald:
> At least in my subjective testing I can't tell any difference anymore,
> so it boils down to design criteria, code size, ability to maintain...
And of course as needed further - preferably at least somewhat
comparable - test scenarios and benchmarks with realistic workloads. Some
thoughts about this:
http://bhhdoa.org.au/pipermail/ck/2007-June/007879.html
Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Martin Steigerwald wrote:
> Am Sonntag 10 Juni 2007 schrieb Linus Torvalds:
>
> Hi Linus!
>
>
>>Ehh.. It was tested extensively by lots of people. It was in -mm for a
>>while, and yes, there have been tons of people testing both. I've
>>followed it, and it seems fair to say that yes, Ingo took a lot of
>>ideas from SD, but CFS seems to have gotten more people involved, and
>>we had several people compare the two, and CFS was generally better.
>
>
> Well actually I did not see that general result yet. I have seen quite
> some testings and quite some reports on the ck patch mailinglist also
> where in favor of SD. If it matters I will collect those, but I think
> Ingo already did include most of them in his summary.
I'd just like to say that last time I tested CFS it was very slow
on context switching. I don't know if this has been improved, but I
think it should be.
I'm not talking about context switching with heaps of tasks, but
about lmbench 2-task ping pongs and such.
Also it used pretty small timeslices to achieve interactivity, which
didn't seem like a good idea. I wonder if that's been fixed?
--
SUSE Labs, Novell Inc.