Alternative Linux CPU Scheduler

[FatBastard]

For the brave and experienced among you guys,

http://linux-dev.qc.ec.gc.ca/

its a "Completely Fair Scheduler". Its stable enough for me, but if you are launching a space shuttle today, you might prefer a more mainstream kernel build.

FB.

[Kooldino]

So what does this time slice differently than the standard kernel?

[FatBastard]

The scheduler is competely fair. this means that if two processes require 100% cpu, they both get the same time excactly, no runqueues, no heuristics of any sort (trying to "guess" according to history etc..).
scheduling bias is set only by niceness, as it should be (IMHO). Its a complete rewrite of the vanila kernel scheduler. if your running a decktop box. u can give it a try.

[Kooldino]

The scheduler is competely fair. this means that if two processes require 100% cpu, they both get the same time excactly, no runqueues, no heuristics of any sort (trying to "guess" according to history etc..).
scheduling bias is set only by niceness, as it should be (IMHO).

Is Niceness the "NI" column in the command line tool "top"?

How does one set niceness?

[FatBastard]

$> nice <nice_value> <command>

there is a renice utility if u wonna Change priority of already running processes (by process id, group , or user)

if u r running gnome, there is a build it "system Monitor" applet, similar to windows's "task manager", you can graphically change a process's priority. very useful.

when I run my huge ant build, I usually renice the eclipse ide to lower priority, so I can youtube without annoying freezes. takes an extra 3 min though.

[DGhost]

and hence why a completely fair task scheduler is not nessicarily the best thing ever...

generally speaking, when doing desktop work, you don't want a fair task scheduler... you want one that gives priority to interactive applications and lowers the priority of background services...

and before it's suggested... it's not the job of the Window Manager or X Windows to set priority of programs. it would likely take some interaction with them, but there is no way that the actual shell should be determining priority of the processes it's running...

now if you are talking server side stuff... then yes, completely fair is a good thing. but for desktop use... not so much.

[FatBastard]

and hence why a completely fair task scheduler is not nessicarily the best thing ever...

Of course not. The best thing ever is cold cranberry vodka in mid July.

generally speaking, when doing desktop work, you don't want a fair task scheduler... you want one that gives priority to interactive applications and lowers the priority of background services...

.....

now if you are talking server side stuff... then yes, completely fair is a good thing. but for desktop use... not so much.

its actually meant to be used as a desktop kernel patch.

http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt

I'd like to give credit to Con Kolivas for the general approach here:
he has proven via RSDL/SD that 'fair scheduling' is possible and that
it results in better desktop scheduling. Kudos Con!

and before it's suggested... it's not the job of the Window Manager or X Windows to set priority of programs. it would likely take some interaction with them, but there is no way that the actual shell should be determining priority of the processes it's running...

I personally find it very suggnificant to my productivity, being able to manually renice processes. sometimes I run stuff that takes ages to compete, and uses up most of the cpu (building huge java projects or ripping DVDs (ehh make it backing up DVDs ..) are two examples that comes to mind) I don't mind if a command takes up an extra 5 min to complete, as long as I can do other stuff with my machine during.
of course renicing can be done without a special kernel.


The bottom line (if there is one at all) is just keep 2 (or more) kernels, no harm in switching.
the cfs project has apt and yup repositories so its even easy to maintain (no need to build the kernel yourself).

[DGhost]

indeed. you could renice programs under linux for as long as i can remember

all in all the project looks to be a good step in the right direction, but simply for the fact that linux task scheduling has been crap for a really long time. it had way too many problems and had grown way too complicated over time. in fact, there have been quite a few other attempts at tuning the scheduler over the years - but all they really did is build on the flaws instead of trying to fix the fundamental design flaws. so any improvement is good to make.

so yes, it shows benefits over the stock kernel. but... again... the true benefits of a "completely fair scheduler" are predominantly on server applications. you generally don't want a fair scheduler on a desktop, as in order to get the best performance you wind up with having to do exactly the opposite - being unfair in which processes get priority and which ones don't.

until the kernel monkeys figure this sort of thing out and implement a proper method to give interactive processes priority over background processes (hell, you could do probably use the CFS to implement it using a per thread granularity, allowing interactive apps to get attention more frequently than their breathren, even at the same run level), they might as well be barking up the wrong tree.

[FatBastard]

I agree that there is a long road ahead (till Linux gets to schedule like FreeBSD ;-) ). I don't think one approach would win, or that there even a competition. I think that we are gonna see easier to use and more powerful kernel tweaking tools. again, the cool thing is that if you can't tell the difference between a kernel and a toaster, your fine using the mainstream stuff.

what is server side stuff ? daemons running in the background serving requests. I have a server machine which runs svn, cruise control ,wordpress , and rsync. it also runs an apache 2 for testing. now, the apache is constantly handling hundreds of requests. the svn is the 2nd most active, the wordpress (I use it as a wiki) is 3rd, and the rsync is the least active.
in this case I don't mind and actually prefer the kernel scheduler to practice heuristics and any other algorithm to give scheduling bias to the apache 2.

When it comes to desktoping, I usually have an IDE running, Firefox , Thunderbird some terminals etc ... typical desktop stuff. now, when I bring one of these applications into focus, I do not want it to wait for other stuff because it wasn't used recently.
I.E I coded Java for 3 hours , so the eclipse IDE gets a scheduling bias, now I wonna take a break (watch some boobs with Firefox), I don't want to wait until the kernel brings FF from the dead. I want my boobs now!. this is why I think fair scheduling has a place in desktop usage.

[FatBastard]

CFS is being merged into the mainstream linux kernel.
apparently this has been decided yesterday.

http://kerneltrap.org/node/11737

Ingo Molnar [interview]'s Completely Fair Scheduler [story] has been merged into the Linux kernel for inclusion in the upcoming 2.6.23 release. A comment in the patch titled 'sched: cfs core code' noted, "apply the CFS core code. This change switches over the scheduler core to CFS's modular design and makes use of kernel/sched_fair/rt/idletask.c to implement Linux's scheduling policies." Another patch included documentation which described the new scheduler, "80% of CFS's design can be summed up in a single sentence: CFS basically models an 'ideal, precise multi-tasking CPU' on real hardware." It goes on to explain:

"CFS's task picking logic is based on this p->wait_runtime value and it is thus very simple: it always tries to run the task with the largest p->wait_runtime value. In other words, CFS tries to run the task with the 'gravest need' for more CPU time. So CFS always tries to split up CPU time between runnable tasks as close to 'ideal multitasking hardware' as possible.
"Most of the rest of CFS's design just falls out of this really simple 32 concept, with a few add-on embellishments like nice levels, 33 multiprocessing and various algorithm variants to recognize sleepers."

Credit was given to four developers other than Ingo Molnar: "Con Kolivas, for pioneering the fair-scheduling approach [story]; Peter Williams, for smpnice; Mike Galbraith, for interactivity tuning of CFS, Srivatsa Vaddagiri, for group scheduling enhancements [story]".
The CFS scheduler replaces Ingo's own O(1) scheduler which was first proposed on January 3rd, 2002 [story], and merged into the 2.5.2-pre10 kernel a few days later, on January 8th [story].

[Nowhere]

Can parts of the above quote be summarised as "CFC models ideal multi CPU enviroment (one cpu per task/thread/process/whatever) on limited number of CPUs"?

[FatBastard]

Can parts of the above quote be summarised as "CFC models ideal multi CPU enviroment (one cpu per task/thread/process/whatever) on limited number of CPUs"?

All schedulers justify their existence when a cpu hungry set of application, is running with limited number of CPUs (as opposed to unlimited number of cpus ???).

but yeah, I agree with your understanding that CFS is going to do a better job scheduling CPU time when a machine is stressed.

in any case, this has been my experience so far