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:
signature.asc
Description: This is a digitally signed message part.
- Follow-Ups:
- Re: [ck] Re: Linus 2.6.23-rc1
- From: Sam Ravnborg <[email protected]>
- Re: [ck] Re: Linus 2.6.23-rc1
- References:
- Linus 2.6.23-rc1
- From: Linus Torvalds <[email protected]>
- Re: [ck] Re: Linus 2.6.23-rc1
- From: Jan Engelhardt <[email protected]>
- Re: [ck] Re: Linus 2.6.23-rc1
- From: Linus Torvalds <[email protected]>
- Linus 2.6.23-rc1
- Prev by Date: Re: TCP SACK issue, hung connection, tcpdump included
- Next by Date: Re: LinuxPPS & spinlocks
- Previous by thread: Re: [ck] Re: Linus 2.6.23-rc1
- Next by thread: Re: [ck] Re: Linus 2.6.23-rc1
- Index(es):