Re: [ck] Re: Linus 2.6.23-rc1

Martin Steigerwald
2007-07-29T09:04:58Z

[-- 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 --]