The Really Fair Scheduler

derrida writes "During the many threads discussing Ingo Molnar's recently merged Completely Fair Scheduler, Roman Zippel has repeatedly questioned the complexity of the new process scheduler. In a recent posting to the Linux Kernel mailing list he offered a simpler scheduler named the 'Really Fair Scheduler' saying, 'As I already tried to explain previously CFS has a considerable algorithmic and computational complexity. This patch should now make it clearer, why I could so easily skip over Ingo's long explanation of all the tricks CFS uses to keep the computational overhead low — I simply don't need them.'"

Comments

More flame bait?

[Bryan Ischo]

I read the article in question. There is obviously much disagreement about the value of the Really Fair Scheduler, and so I must assume that "derrida" and the Slashdot editors are once again just trying to invite more people to the flame-fest as usual.

The comments on the article at the linked-to site suggest that there are potentially flaws in the logic behind the Really Fair Scheduler, and that its author has ignored advancements in the CFS that make most (or all?) of its improvements irrelevent. Also there are many suggestions that the author of the Really Fair Scheduler, some guy named Roman something-or-other, is raging on the kernel lists rather than working cooperatively to improve the Linux scheduler.

Given what I have seen, I suspect that the Really Fair Scheduler is going nowhere, and that "derrida" knows that and is just trying to add more fuel to the flame-fire by posting about it on Slashdot.

Re:More flame bait?

[Dr. Spork]

You could be right, but Roman is in a tough position, because he's arguing for a change that he thinks is big, and Ingo seems to be trying to sap his enthusiasm by telling him to essentially "work on what we're doing" when Roman wants to have a debate about the best architecture for the scheduler.

In order to help give substance to the debate, Roman coded together some proof-of-concept stuff, but instead of his architectural ideas being looked at seriously and critically, Ingo instructs him to strip away most things and "well use it." That really should seem to everyone on the sidelines like Roman's ideas are being ignored without debate. Now, maybe Ingo is polite, Roman's work just sucks, and Ingo won't confront him on it. But if that's not the case, maybe there should be a (non-flamey) debate about the best architecture for the scheduler.

Re:Coming soon

[arth1]

You're more insightful than you think. I don't want a fair scheduler. I want a very unfair one, that favours my favourite processes. And I want one that has as little overhead as possible -- a scheduler so complex that it eats 20% of the available cycles just to figure out who to give the remaining 80% to, I have no use for.

But where is the Linux IO Scheduler?

[Anonymous Coward]

Screw the CPU scheduler at this point. The kernel folks are missing the obvious and utter brokenness of the IO scheduling. These bugs have been outstanding about a year now!! And it's not just AMD64 anymore either. Quoth the kernel bug report:

"Now, as far as this bug being AMD64 only. We develop a portable data analysis
tool and we run it on Intel Core Mobile systems (Sony UX series, Panasonic
Toughbook series) and see this bug or one almost exactly like it on those
platforms as well.
"

http://bugzilla.kernel.org/show_bug.cgi?id=7372
http://bugzilla.kernel.org/show_bug.cgi?id=8636
http://www.nabble.com/IO-activity-brings-my-deskto p-to-its-knees-(2.6.22.1-ck1)-t4192136.html
http://forums.gentoo.org/viewtopic-t-482731-start- 500.html

At first, deadline IO was touted as an answer, but that doesn't completely fix things.
Some say Native Command Queueing is broken. One person claims deadline + NCQ disabled helps.
Some say the kernel's vfs_cache_pressure settings help, while others refute it (compare kernel bug report versus page 21 of the gentoo forum thread). But no one understands what's really broken in the kernel.

Can we please get Ingo working on IO scheduling? PLEASE?

Re:Why not swappable?

[Anonymous Coward]

Then don't allow them to compile schedulers as modules -- force each kernel to have a single scheduler built in.

Hooray for rebuilding the kernel and rebooting whenever you want to switch to a different workload!

Re:Why not swappable?

[Anonymous Coward]

as opposed to always running with a scheduler unsuited to your workload?

Mod parent up

[ardor]

He's right on. IO has a much bigger impact.

Re:Why not swappable?

[treke]

The simplest answer is that the developers who have the final say don't want to do it that way. They think that it's better for the kernel to have one single scheduler that gets widely tested against every type of load than to have multiple schedulers that tend to only get tested in their areas of optimization.

Math is only reliable up to a point

[Goonie]

A fair proportion of the time, the mathematics applied in computer science (and, probably, most other disciplines) starts with simplifying and often unrealistic assumptions.

Not that maths isn't useful, but much of the time it can't give you definitive answers for the questions you really want answers to, only somewhat related, simpler ones.

Re:Interestingly rigorous

[HeroreV]

When will people learn that being rude doesn't help? If you want somebody to work with you, you need to play nice. It's not pleasant, and it's not easy to make yourself calm down and act like a pussy, but it's important if you ever want any collaboration.

Example:

Interesting, but I don't see this. Can you point it out?

I think you misunderstood me. It may not be a common problem, but it is a conceptual problem. The rounding has been improved lately, so it's not as easy to trigger with some simple busy loops. Peter's patches don't remove limit_wait_runtime() and AFAICT they can't, so I don't see how what you said can be correct.

I'm worried about how quickly you judged this issue, and that you haven't been more in contact with me discussing it. This issue is important to me, and I'd really like to work with you to get it resolved.

Now for the important question

[DeVilla]

Does Linus like him? More than Ingo?

Re:Review feedback

[scumdamn]

Speaking of unfair, I think it's completely unfair for you to ruin a wonderful flame war based on supposition and misunderstanding. How dare you roll up on Slashdot busting caps with your reasoned approach, data, and project management skills? Now this topic of conversation is hosed because nobody can BS their way through why you're a bad guy who's stepping on Roman's neck because of some daddy issues or something. Sheesh, of all the gall...