Con Kolivas Contemplates Ending Kernel Development, Retiring MuQSS & -ck Patches

[polarathene]

One issue with MuQSS (and some others like BMQ I think?) was lacking/broken cgroup support. I think it was just CPU accounting was inaccurate, but that impacted software like some OOM tools at least with that PSI metric IIRC, prevented some niceness software working correctly (anicey or something like that), I think it possibly affected Docker and/or some disk I/O scheduler features in BFQ.. mostly things that go on under the hood to provide better functionality/experience.

MuQSS (and IIRC, BMQ) stubbed the cgroup stuff with no intention to support it. I think because their approaches conflicted with that functionality or something.. I remember reports of process monitors getting inaccurate CPU usage readings too, brief look at my notes this is apparently due to mixing MuQSS with full tickless kernels. Might throw off CPU governor like schedutil too I guess?

For casual users, those issues might not matter and they get a positive outcome with no drawbacks, but for some devs/deployment machines that tradeoff might be acceptable.

---

I assume financial support won't motivate the work to continue, otherwise he could probably give that a shot if there's enough interest to back it.

[F.Ultra]

It's great that everyone here quotes Torvalds exclusively but you know in any conflict there are two sides and no one has posted anything by Con Kolivas as if there's just his scheduler created out of nowhere with no one behind it. Also, it looks like folks here strongly imply Torvalds is infallible.

I'm not skilled enough to comment on anything Torvalds says but the way I see it, you choose a scheduler on boot and that's it. Does it matter what data structures it operates with when those are not used by anything else or are they?

No one here quote Kolivas responses to Torvalds claims due to him not have made such responses, the complete thread of discussions on lkml was available on the link that was posted with the first quote.

Also no one is claiming that Torvalds is infallible, he is though regardless of if you like it or not, the gatekeeper here, so if you want to know why the patches was never accepted, he is definitely the one person to go to for an explanation. And as he wrote "And hey, you can try to prove me wrong. Code talks. So far, nobody has really ever come close.", still 14 years later and no one have done that.

And as Torvalds wrote, yes data structures matter when it comes to the scheduler, performance will drop for everyone. Having something be pluggable always have a performance impact, for IO schedulers that is not a problem since the IO have such a large overhead anyway.

[binarybanana]

Wow, that sucks. I've been using -ck for a few release cycles now and it improves on latency massively. It even improves FPS in a lot of games. Maybe there are some knobs to tweak CFS to get similar results, but I'm not so sure. Patching -ck to work on 5.13 is relatively easy, but going forward that might not be the case for long. Seems like 5.14 already makes it difficult. I hope MuQSS gets maintained by others as part of Xanmod and the like at least, or I have to try some of the other schedulers. CFS is noticeably worse on desktops if you value interactivity/liow latency and even throughput in the cases.

[waxhead]

We already have multiple IO schedulers. Please find a reason why we can't have multiple process schedulers.

Alright - the reason is that we should not have multiple process schedulers because we then duplicate a system that creates more configuration problems than it solves.
Ideally we should not have more than one IO scheduler either and the only good reason to replace it is if there is something new that is better in every way.

I must admit that I love to fiddle with IO schedulers and I really like the "hotswappable" policy, but really - when you think about it - it is fundamentally wrong the way I see it.

[avem]

Alright - the reason is that we should not have multiple process schedulers because we then duplicate a system that creates more configuration problems than it solves.
Ideally we should not have more than one IO scheduler either and the only good reason to replace it is if there is something new that is better in every way.

I must admit that I love to fiddle with IO schedulers and I really like the "hotswappable" policy, but really - when you think about it - it is fundamentally wrong the way I see it.

I don't know man. A company which has thousands high-performance dual-socket servers with terabytes of storage (including iSCSI) may have different preferences in terms of executing IO requests than a person with an average laptop. I might be wrong, of course.

[waxhead]

I don't know man. A company which has thousands high-performance dual-socket servers with terabytes of storage (including iSCSI) may have different preferences in terms of executing IO requests than a person with an average laptop. I might be wrong, of course.

I don't think you are wrong. I think you are absolutely correct - they do have different preferences, but that is usually for a reason right? So if that reason goes away regardless if it is process or I/O scheduling it becomes mostly a non-issue. The downside is that it will be less fun and less rewarding to not be able to experiment.

[kiffmet]

What on earth does MuQSS (a process scheduler) have to do with BFQ/PDS (I/O scheduler.)

Sorry, I meant BMQ and mistyped. Both BMQ and PDS are available as a single combined patch, called ProjectC. PDS is a process scheduler aswell btw. You can choose between the two and stock CFS via your preferred way of configuring kernel options before build.

[4BvFCHGlspF4]

Technically there have been zero reasons not to mainline your code.

No, there hasn't. But contrary to what you're implying, it has nothing to do with any current or former kernel maintainer either. Not... a... single... thing. It has everything to do with Con himself. Did you even read his goodbye blog post? Really read it carefully? Because all I'm seeing, when I'm reading that, is the whining of a man that does not play well with others, a man whose ego is so monstrously huge that one would think he perceives himself to be the second coming of, well, whatever Messiah or savior of the world you happened to believe in.

Here, let's start here:

Unfortunately I also do not have faith that there is anyone I can reliably hand the code over to as a successor as well, as almost all forks I've seen on my work have been prone to problems I've tried hard to avoid myself.

Oh, really, Con? Really? Your code is that far out there? So far beyond us mere mortals that we have no hopes of ever understanding it, let alone maintaining it or improving upon it?
And that remark of his, well, it becomes much more ironic and funny once you factor in the fact he's never been willing to keep up his work with kernel point releases. A fact he's made abundantly clear more than once over the years. Those point releases, well, we need those. Far more than we need MuQSS. Infinitely more so even.

Let's continue:

There is always the possibility that mainline linux kernel will be so bad that I'll be forced to create a new kernel of my own out of disgust

The arrogance here is so far beyond anything even remotely normal or reasonable that I suspect, with good reason and with a solid background in mental healthcare, that the man actually suffers from something along the narcissistic spectrum. And yet, still unwilling to maintain his code to follow point releases. So, lazy to boot. Arrogant and lazy.

This in conjunction with his profession is just bizarre really. He obviously does not play well with other kernel developers, that much is obvious. Either by choice or by consequence, he just hates them. That much is painfully clear. Now, his profession kind of DEMANDS that he plays well with others. He's obviously going to be in a small room with other people with large egos (surgery room) on a regular basis, given his profession. How does he do this but then does not manage to overcome his gripes with the kernel developers, people he would not even have to meet in real life to work together with.

I'll tell you why -- Because the problem is his, no one else's. It has nothing to do with Linus Torvalds, Greg Kroah-Hartman or anyone but Con Kolivas. He is the sole reason his work was never mainlined nor will it ever be mainlined. Now, if he could come down from his self-imposed pedestal and tone his ego down by, oh, I don't know, let's ballpark it... 99%, he'd quickly realize that he is not the second coming of whatever. He never was. He's one man. An intelligent man, to be sure. But, still, just a man. Just a human. Fallible like everyone else. Heck, I've seen BFS/MuQSS throw up more than a few issues over the couple of years I did use it. So, there, evidence that his code is, much like anyone else's code... not beyond reproach.

Speaking of that code... yeah, not gonna miss it. Since he obviously quit some kernel versions ago, well, it indeed is now not only outdated but actually was surpassed by CFS' own performance. I literally do not miss it one bit. Constant hardware support improvements, security improvements, scheduler improvements, IO improvements are infinitely more important than lingering with 1 CPU scheduler that is not even updated to point releases. So, yeah... buhbye Con, don't let the door hit you on the way out.

And, for the record... no, this wasn't personal. I just detest people in general, especially people that are far more arrogant and pedantic than their contributions warrant.