Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald <Martin@lichtvoll.de>]

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

Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> > You cannot please everybody in the scheduler question, that is clear,
> > then why not offer dedicated scheduling alternatives (plugsched comes
> > to mind) and let them choose what pleases them most, and handles
> > their workload best?

[...]

> So I personally think that it's much better to find a setup that works
> "well enough" for people, without having modal behaviour. People
> complain and gripe now, but what people seem to be missing is that it's
> a journey, not an end-of-the-line destination. We haven't had a single
> release kernel with the new scheduler yet, so the only people who have
> tried it are either
>
>  (a) interested in schedulers in the first place (which I think is
> *not* a good subset, because they have very specific expectations of
> what is right and what is wrong, and they come into the whole thing
> with that mental baggage)
>
>  (b) people who test -rc1 kernels (I love you guys, but sadly, you're
> not nearly as common as I'd like ;)
>
> so the fact is, we'll find out more information about where CFS falls
> down, and where it does well,  and we'll be able to *fix* it and tweak
> it.

I have nothing against CFS in the kernel. I had as long as my ThinkPad T23 
had interruptions in music playback initially even though the machine was 
idling - while at the same time music playback was perfectly fine with SD 
since quite some iterations. After quite some iterations of testing new 
CFS versions from Ingo it started working like I think it should. 

Expecting a interruption free music playback IMO by no way is any mental 
baggage. I for sure am interested in schedulers, but actually I do not 
understand the exact principles by with SD and CFS work, I just had no 
time to look at them closer, and thus just looked at: How does it behave 
on my laptops with different desktop loads? Actually from a technical 
point of view I do not care whether CFS or SD goes in, cause I simply 
understand enough of the technical concepts behind them. And since they 
are behaving roughly the same on my laptops now I have no issue with CFS 
going in from a functional view. It seems to do what I expect from a 
scheduler and I am happy with that.

While I have nothing against CFS in the kernel, I actually do not like the 
way the decision was done and how it was communicated. Its not the 
outcome of the decision but the way it was done that bothers me. I 
actually also think that the communication between Ingo and Con could 
have been better especially when Ingo decided to write CFS while Con was 
still working hard on SD.

I do think that it would not have been necessary to loose Con's talent. 
Sure I think that Con had its share in it, but it does not make sense to 
concentrate on his share, cause only he can do that and he is gone for 
now. But thats exactly what I perceive you are doing. 

And I realize it doesn't make sense for me at all to concentrate at your 
or Ingo's share. I made my point and unless you Ingo and the others 
involved decide to look at whether there might be something you have done 
that has contributed to loosing the talent of a good kernel developer the 
issue can't be helped. Unless people decide to look at themselves instead 
of pointing out what in their eyes has been wrong with others, the issue 
will stand still.

I am pretty confident that SD in the kernel would have been a viable 
choice as well and that Con would have done his best to support and 
maintain it. Well now thats history. Con decided to stay out of kernel 
development and I actually can understand him.

I believe it is possible to learn something out of how this all happened. 
And actually I merely wanted to point this out to you. Whether you decide 
to learn something out of it or not, actually is your choice. 

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]