Re: Scheduler Situation

["debian developer" <debiandev@gmail.com>]

On 8/3/07, T. J. Brumfield <enderandrew@gmail.com> wrote:
> First off, I am an avid reader of the LKML but I'm not a developer.
> Admittedly I am a piss-poor C developer who likes to poke around the
> code, play with patches and attempt to learn, but in reality at best I
> pretend I understand it, and I don't really.  I fully defer to the
> technical knowledge of far greater minds on this list.  Even having a
> basic understanding of C and looking at the code, I still don't
> understand basic kernel operations like memory management or CPU
> scheduling well enough to see in code what works best.
>
> What I can say, is that someone who has had years of project
> management experience, it is painfully obvious here that there are
> events here in personal issues which should be easy to spot and
> rectify.
>
> I, like many people, had been using Con's patches for years and were
> greatly pleased by them.  I've experimented with a variety of kernel
> flavor and patches, often woefully trying to amass my own collection
> of custom patches and often breaking things while trying to integrate
> too many patches at once that don't patch nicely with one another.
> And when I've had questions, I often read through Con's mailing list
> archives from his site.
>
> It would appear he spent 4 years working on his patch-set, primarily
> based around his version of a scheduler.  And in reading the LKML it
> seems that aspects of his patch-set he pushed for mainline inclusion.
> He was shot down saying that his ideas were flat-out wrong, and still
> he worked for years to improve his work.  He answered questions, fixed
> bugs, and made himself very available.
>
> It may very well be that CFS is a better scheduler than SD.  Ingo is a
> very respected coder, and from even Con's mouth it seems that CFS is
> pretty simple in its execution.  Ingo seems to suggest that since he
> posted his code so quickly after he wrote it, that he didn't do
> anything wrong.
>
> Linus, a man I greatly admire and respect, especially for his
> blunt/terse statements, also seems to suggest that no one has wronged
> Con here.  However in insisting that the decision was based on Con's
> inability to support his code, I can fully understand why Con would
> leave kernel development permanently.
>
> The simple truth is that Con poured years into a project despite being
> rebuffed and told he was wrong.  The moment that people change their
> minds and realize that his concepts have merit, no one apologizes for
> all the past criticism.  Ingo did very much credit Con for
> inspiration, but I can't see how this decision was anything but
> political.  Linus said it himself, that he trusts Ingo to stand behind
> the code, and he didn't trust Con to do the same.
>
> I am reticent to accuse anyone of dishonesty, but that statement just
> doesn't seem to add up.  And even if that is the way Linus truly felt,
> it doesn't seem fair given how well Con had supported his code and his
> users.  Regardless for a man who claims to not make political
> decisions on code, that is exactly how he operated here.  He chose the
> person over the code.  From his own mouth, it seemed he remains very
> put off by earlier comments from the "Con camp" that perhaps there
> should be separation between the server and desktop kernels.
>
> And while Linus is no-doubt correct that such a separation should not
> occur, I never really saw Con push for such a thing.  I know I don't
> fully understand the code, but it does seem to make sense to an idiot
> like me however that with all the other kernel options to customize
> your build for your needs, it isn't beyond reason to go with a
> plugsched type solution.  The kernel is already immensely modular, no
> doubt the most modular piece of code on the planet.
>
> It works amazingly well in small embedded devices to large
> multi-processor servers across multiple architectures and processor
> types.  The reason I'm posting on an issue I'm sure that many people
> are already sick of, is that I'm sure many people would like to see
> two things happen.
>
> 1 - Can someone please explain why the kernel can be modular in every
> other aspect, including offering a choice of IO schedulers, but not
> kernel schedulers?

Good question. has been answered in other threads. Linus does'nt like
having separate kernel schedulers.