Linux,  Uncategorized

The end of the CK kernel patch set

Today kernel developer Con Kolivas announced that he will stop developing his Linux patch which improves desktop performance. For people who have followed recent discussions about his SD CPU scheduler and about the inclusion of his swap prefetching patches in the Linux kernel this will not come as a surprise.

The CK patch set was popular especially amongst desktop users who want to get maximum performance out of their machine. The CK kernel came with a different CPU scheduler (first Staircase, later SD), which improves the smoothness of desktop applications (for example no more sound stuttering), the mapped watermark patches, which makes the OS use less swap, and the swap prefetching patches, which makes the system more responsive after a memory hungry application caused others to be temporarily swapped out. The CK patch set was also used in several distro kernels, such as the Mandriva’s tmb kernel and kernels in Gentoo and Arch Linux.

The decision to completely stop kernel development, came after the critical reactions by other kernel developers about the SD scheduler and swap prefetching. After the first releases of the SD kernel, some developers preferred trolling instead of helping out to fix the problems which existed at that time. While the SD scheduler slowly became more and more stable, only thanks to Con Kolivas efforts, a competing scheduler (CFS) which was based on the same concepts, was started. Now that both schedulers are mature and stable, a lot of CK kernel users and Con Kolivas himself are left wondering why it was even necessary to start competing with SD, instead of uniting all powers to make one great scheduler.

Swap prefetching was already proposed for inclusion in the Linux kernel a long time ago. But several developers remained critical, while a lots of users reported improvements by these patches. The patches were included in the mm kernel, but developers did not really review it and proposed it for the mainline kernel. Until Ingo Molnar finally stepped up recently, and gave some positive comments after a code review. Again some developers started criticizing the patch, and the future of this patch became again unclear.

With all this in mind, it’s normal that Con Kolivas got fed up with Linux kernel development. It seems some Linux developers really need to do something to improve their communication, and need to be a bit more reasonable and constructive, instead of immediately criticizing one’s efforts. This is at least the second kernel developer who got fed up with the way the Linux kernel development goes in a short time.

Developers come and go, that’s a normal process. Still I think Con Kolivas’ departure could have been avoided. In the end, we can only thank him for his great work, which certainly was not useless. In the end, the CFS scheduler which will be included in Linux owes a lot to Con Kolivas’ ideas, and I hope the other patches will find their way to inclusion in other patch sets in way or another.


  • damaged justice

    “…wondering why it was even necessary to start competing with SD, instead of uniting all powers to make one great scheduler.”

    Because that’s how free software works. It may not be as “efficient” as everyone moving in lockstep, but that freedom to fork is a fundamental neccessity. For whatever the reason, individuals chose to do their own thing. It may take longer, but what’s the rush? It’s not about the destination — it’s about the journey.

  • Frederik

    Actually CFS was not a fork, but a complete rewrite, based on the same ideas as SD.

    And yes, the freedom to fork is important in the free software world, and sometimes is necessary. But in this case, developers chose to start competing with SD without giving SD a fair and reasonable chance.

    Sure, there were some problems with SD in the beginning. And Con Kolivas had trouble fixing some of the bugs very quickly because of his illness.

    But the fact that SD is now very stable, and is considered by many as a reference implementation which CFS has to beat, is the proof that there was no valid reason to actually be so negative about it as several people were. Almost nobody cared to review SD in detail, and cared to give really constructive comments. Several developers instead started trolling (stating that a fair scheduler could never work and that his efforts were “an utter failure” and starting useless discussions whether SD was really a fair scheduler).

    Today SD works fine for many people, so why had there to be such harsh comments? I can understand very well how Con Kolivas feels now about all this and prefers not to waste anymore time with kernel development if people are so negative about this efforts.