MuQSS/CK's Con Kolivas Becoming Concerned Over The Increasing Size Of The Linux Kernel

Longtime independent Linux kernel developer Con Kolivas known for his work previously on the BFS scheduler and now the MuQSS scheduler as well as his out-of-tree "-ck" patch set is becoming increasingly concerned over the growing size of the kernel code-base and that ultimately could put an end to his work with a focus on greater desktop interactivity/performance.

Kolivas stopped contributing to the mainline Linux kernel a decade ago but has continued maintaining the "-ck" patch-set for each new kernel release as well as working on the likes of the Brain Fuck Scheduler and Multiple Queue Skiplist Scheduler. Generally he's been quite punctual in re-basing the work for new kernel releases aside from when the retired anaesthesiologist took a break earlier this year to design equipment for the COVID-19 battle. But now his latest battle is the increasing size of the Linux kernel that often brings core infrastructure changes as opposed to just new drivers.

With Linux 5.8 being one of the largest releases ever, he took the opportunity in explaining why his MuQSS/CK patches have yet to be re-based. Kolivas noted, "It's fair to say that my motivation for keeping up with linux kernel development has been flagging for some time now and the current world situation is not helping. Hearing the news extol the virtues of linux-5.8 being the "biggest release ever" does not particularly aid my situation. If it were just a massive drop of new drivers I could understand that, but usually it just means yet more rewrites of major infrastructure within the kernel in the quest to "make it better." Personally I don't think it's such a great thing, but that's a debate best left for elsewhere."

For now at least he does plan to continue re-basing his kernel patches to new versions albeit isn't sure on any timeline. He also further explained his biggest concerns in all the work on his out-of-tree code, "My biggest concern with the massive churn is me screwing something up in a way that leaves users of my code open to security issues or fatal data corruption at some stage because I haven't been careful enough to protect against this happening. For this reason I've often considered abandoning the code entirely but some supportive individuals have stated they find comfort in the relative stability and continued utility of MuQSS's code in the increasingly volatile kernel churn world which is reassuring and encouraging enough for me to at least plan to stay in sync."

With the increasing complexity and new features being introduced, ultimately MuQSS could be pushed out of relevancy or the feasibility of maintaining it. "As time goes on and more and more features get added to the scheduler that have nothing to do with ordinary desktop and mobile platform usage, at some stage distributions will be tempted to become dependent on one or more of those features and if I don't develop MuQSS much further to incorporate my own version of those features, it will become redundant. Given the completely different scheduler architecture of MuQSS versus CFS means I can't simply just port over the code most of the time; I have to write my own complete feature equivalent version and these are far from trivial. The accounting code is completely different, most of the CGROUP features aren't even implemented, and deadline scheduling is not available at all for example. If more of these appear in the future and eventually become showstoppers, then unless some miracle happens to make me find the motivation to work on them, it will be the death of it."

More details on CK's blog.