Interview with ex-linux-kernel developer Con Kolivas

[Brazen]

Ok, so it's not all about why they both suck, but he makes some fascinating points (IMO) on the current state of computing and what it's like working with (or trying to) the mainline kernel developers. The article is long, and once I started reading it, I couldn't put it down.

link to article

link to slashdot article where I found it

With a truckload of help from William Lee Irwin III (who wrote the main architecture) I posted a pluggable CPU scheduler framework that would allow you to build into the kernel as many of multiple CPU schedulers as you like and choose at boot time which one to run. I planned to extend that to runtime selection as well. This is much like the modular pluggable I/O scheduler framework that Linux kernel currently has. It was flat out refused by both Linus and Ingo (who is the CPU scheduler maintainer) as leading to specialisation of CPU schedulers and they both preferred there to be one CPU scheduler that was good at everything. I guess you can say the CPU scheduler is a steamroller that we as desktop users use to crack nuts with, and they didn't want us to build a nutcracker into the kernel.

 

[Nothinman]

I haven't read the article yet, the site was having problems keeping up when I tried earlier, but in my following of lkml I've seen Con's stuff get dropped with what seems like very little real consideration. The main problem is that it's hard to quantify desktop responsiveness with numbers and benchmarks. Whenever someone increases the throughput of some device, filesystem, etc or decreases the latency or code size of something it's really easy to build, benchmark and provide the numbers so that anyone with a clue can look at it and decide whether the changes are worth whatever's been changed. But saying "My WM is more responsive with this CPU scheduler." doesn't mean much.

 

[Brazen]

Originally posted by: Nothinman
I haven't read the article yet, the site was having problems keeping up when I tried earlier, but in my following of lkml I've seen Con's stuff get dropped with what seems like very little real consideration. The main problem is that it's hard to quantify desktop responsiveness with numbers and benchmarks. Whenever someone increases the throughput of some device, filesystem, etc or decreases the latency or code size of something it's really easy to build, benchmark and provide the numbers so that anyone with a clue can look at it and decide whether the changes are worth whatever's been changed. But saying "My WM is more responsive with this CPU scheduler." doesn't mean much.

I don't really consider myself knowledgeable enough to add much worthwhile, but Con says practically they exact same thing in the article. Desktop "responsiveness" is very subjective, but Con says he has gotten lots of feedback that his patches make a difference for the better. I suppose the only thing to do is apply his patchset and decide for yourself.

The good news (for the users, I suppose) is that is sounds like the cpu scheduler is being rewritten based on Cron's work, unless I'm misunderstanding that part of the article.

 

[Markbnj]

I tried to read it earlier and couldn't get the server to respond. Trying again now and it looks like I may get through.

Just to add one bit of general context, though: there are always people who think they have better ideas, and very often they do, who nonetheless can't manage to muster the support to mainstream them. Too frequently they end up bitterly complaining in public.

 

[Nothinman]

I suppose the only thing to do is apply his patchset and decide for yourself.

Well at the very least his swap prefetch patch has been in -mm for a while and it was his staircase deadline scheduler that prompted Ingo to write the CFS scheduler that replaced his O(1) scheduler recently. Some people, including myself, saw the last one as a bit of a dick move by Ingo though since he wrote another scheduler instead of fixing up the staircase scheduler.

The good news (for the users, I suppose) is that is sounds like the cpu scheduler is being rewritten based on Cron's work, unless I'm misunderstanding that part of the article.

That's already done, AFAICT it was merged and released with 2.6.22.

 

[Brazen]

Originally posted by: Nothinman ...
Some people, including myself, saw the last one as a bit of a dick move by Ingo though since he wrote another scheduler instead of fixing up the staircase scheduler.
...

Yeah, I think Cron talked about that in the article and I think that was the "dick move" that pushed him to stop developing for the kernel. I wasn't sure how to take that; I mean isn't that what he's been wanting? a new scheduler based on his work? Or is it a matter of not giving credit where credit is do?

 

[Nothinman]

Yeah, I think Cron talked about that in the article and I think that was the "dick move" that pushed him to stop developing for the kernel. I wasn't sure how to take that; I mean isn't that what he's been wanting? a new scheduler based on his work? Or is it a matter of not giving credit where credit is do?

It wasn't based on his work, just the idea and Ingo did mention him in source and the announcement.

 

[xtknight]

How does Ingo's new scheduler compare to what Con had?

I tried the ck patches and even subjectively I didn't notice that much difference. It just seemed like the slowness was getting juggled around differently, and in some cases, it was worse. Of course, it could have just been my horrible kernel compiling skills, I don't know. Many people noticed a difference.

Whatever the case, I'm really sorry to see him go on this basis. He's one of the few people that can really do this stuff. Besides his scheduler he had many other patches that got into the mainline.

Next, they should talk to Hans Reiser about his problems getting reiser4 into the kernel.