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

[royce]

Sad day. I used CK patched kernels way back when kernel 2.4 or maybe 2.6 and I was using gentoo and compiling absolutely everything on my system and really getting into the meat of Linux in general.

Best of luck to Mr Kolivas.

[tomas]

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

The continuation of Linus's first post reads:

And CPU scheduling really isn't that complicated. It's *way* simpler than IO scheduling. There simply is *no*excuse* for not trying to do it well enough for all cases, or for having special-case stuff. But even IO scheduling actually ends up being largely the same. Yes, we have pluggable schedulers, and we even allow switching them, but in the end, we don't want people to actually do it. It's much better to have a scheduler that is "good enough" than it is to have five that are "perfect" for five particular cases.

Source:
https://lore.kernel.org/lkml/Pine.LN...oundation.org/

[F.Ultra]

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

If you are not going to accept Linus:es reasons then you are not going to accept any one elses. If we continue to quote Linus from the 2007 thread about pluggable schedulers:

Go wild. It's what open-source is all about. I'm not stopping you. I'm just not merging code that makes the scheduler unreadable, even hard to understand, and slows things down. I'm also not merging code that sets some scheduler policy limits by having specific "pluggable scheduler interfaces". Different schedulers tend to need different data structures in some *very* core data, like the per-cpu run-queues, in "struct task_struct", in "struct thread_struct" etc etc. Those are some of *the* most low-level structures in the kernel. And those are things that get set up to have as little cache footprint a possible etc. IO schedulers have basically none of those issues. Once you need to do IO, you'll happibly use a few indirect pointers, it's not going to show up anywhere. But in the scheduler, 10 cycles here and there will be a big deal. And hey, you can try to prove me wrong. Code talks. So far, nobody has really ever come close. So go and code it up, and show the end result. So far, nobody who actually *does* CPU schedulers have really wanted to do it, because they all want to muck around with their own private versions of the data structures.

[avem]

If you are not going to accept Linus:es reasons then you are not going to accept any one elses. If we continue to quote Linus from the 2007 thread about pluggable schedulers:

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?

[pal666]

The kernel developers by turning your efforts down have made it abundantly clear that your open source work and effort are not welcome.

do you know, that maintainer's main job is to say no? otherwise you'll get software full of shit

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

technically patches have to pass review. every developer knows it

[pal666]

while your patches are out of tree, you have to maintain them yourself. that doesn't scale

[pal666]

This has been discussed here on Phoronix in-depth.

it's very unauthoritative source

I'm not a kernel hacker but again from what I've heard from experienced programmers

not everyone who claims to be experienced programmer is worth listening to

here, in Reddit and on Hacker News there are no technical reasons or obstacles in mainlining his code. Someone in the mailing list objected to the very idea of being able to switch process schedulers on boot

which is a technical reason

(I guess it's not that difficult to do it even at runtime - after all the kernel is perfectly able to suspend and resume all running processes).

it's difficult to do it without making other things worse

[pal666]

I'm not skilled enough to comment on anything Torvalds says

he listed number of valid reasons

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?

they at least take space(grep for "cache footprint" in torvalds quote) and to chose you have to do indirection(grep for "indirect pointers" again). and it complicates code, which is also a downside(it's hard for people to work with complicated code)

[indepe]

Another reason to have only one (official) process/thread scheduler is that programs, if their performance depends on the interaction with the scheduler, will get optimized for that scheduler. So if you have one set of programs optimized for one scheduler, and another set of programs optimized for a different scheduler, you are likely to have performance problems when running both on the same scheduler. And you can't have two schedulers running at the same time. (Although you might perhaps have more options on the official scheduler in so far as that makes sense, but then that's an area where "as simple as possible" is often a good recipe.)

[linner]

All of the mainline I/O schedulers still freeze up the whole machine under heavy/large write tasks. It's been like this through decades of various hardware and annoys the hell out of me.

Never tried the -ck patches so I don't know there.