Debating the Linux Process Scheduler

An anonymous reader writes "The Linux 2.6.23 kernel is expected around the end of the month, and will be the first to include Ingo Molnar's much debated rewrite of the process scheduler called the Completely Fair Scheduler. In another Linux kernel mailing list thread one more developer is complaining about Molnar and his new code. However, according to KernelTrap a number of other Linux developers have stood up to defend Molnar and call into question the motives of the complaints. It will be interesting to see how the new processor really performs when the 2.6.23 kernel is released."

In a blind taste test....

[budword]

I doubt any of us could tell the difference. Storm in a tea cup.

more important things

[LM741N]

I know its not easy getting info on wireless chips, but time would be better spent working on something like that. Just look at all the live CD's out there and how many can connect to wifi? Ubuntu and not much else. (note to self- take wifi chip developers out to strip club and get them drunk next time they are in town)

Still don't understand the fixation

[Anonymous Coward]

Another CFS flamewar within 2 weeks of the last slashdot article on it.
http://linux.slashdot.org/article.pl?sid=07/09/01/1853228 [slashdot.org]

And yet the most important performance bugs in the kernel haven't had any updates.
http://bugzilla.kernel.org/show_bug.cgi?id=7372 [kernel.org]
http://bugzilla.kernel.org/show_bug.cgi?id=8636 [kernel.org]

I do not understand the fixation on CPU scheduling when there are so many other things that need attention. [Heck, if disk IO performance is so broken, I certainly don't have the guts to try out the new firewire code in 2.6.22 as well and add another variable into my life.]

Esoteric Discussions

[Archangel Michael]

More importantly, if there are more than one Scheduler, and if someone could tell the difference, why isn't s/he using the ALTERNATE Scheduler and compiling their own custom, tweaked and totally tuned kernel?

Seriously, most people aren't going to notice, and those that do notice, ought to be able to compile their own kernel, and ought to do exactly that. This is nothing short of an esoteric discussion and shouldn't extend beyond kernel developers. Most people don't know, and don't care which scheduler is implemented.

I'm one of those somewhere between caring and not. I only care about the supposed differences in approach to scheduling, and quite frankly, from what little I understand, the various schemes to scheduling have their advantages and disadvantages. I seriously doubt that ONE is better in all circumstances compared to all the others.

Re:Snooze

[EricR86]

If Microsoft or Apple were more open with regards to their kernel development, I'm pretty sure issues like this would be posted here on slashdot - regardless of a favored OS.

Ugh bring back 2.7 please

[maelstrom]

I know they've changed the model of development for the kernel, but how many new schedulers have we gone through between 2.4 and 2.6 now? Maybe it is just me, but the scheduler seems like a pretty important piece of the kernel.... Ripping it out every 6 months and calling it "stable" seems a bit off to me.

Oh well. I guess I'm just getting cranky in my "old" age.

Did the Open Source is about choise 6

[denisbergeron]

Why not having the possibility to choose the sheduler ? What about a modular kernel sheduler, so everyone will be happy.

Flamewars are usual in developer websites

[Spy der Mann]

For example, ReactOS had a flamewar regarding the "stolen code from Windows", and it was nearly identical. There was this obsessive guy that got fed up over nothing just because his pride as a person was hurt. In the end he was just misinterpreting stuff. The other guy tried to be calm and understanding, but it didn't work.

In the end, it's just about one thing: Some developers, no matter how high their IQ is, are too full of themselves because they have a stupid complex and a low self-esteem.

Re:Can someone provide some insight?

[Opportunist]

That sounds sensible. With the increase of Linux boxes run by "average" people (who will not directly notice a difference), the threat of malware for Linux is going to be on the rise, too. And those people usually know how to exploit even the smallest flaws in a system.

Re:That was actually quite fun. Thanks.

[jeevesbond]

What a bunch of babies.

Maybe to you. To me all the flaming and arguing, over a change that will not--apparently--have much of an effect upon the average user, means that the kernel developers are passionate about what they do. It means that, once the dust settles, we'll get a superior product. Maybe if the developers in Microsoft were this passionate Windows would be as good as GNU/Linux.

If you're not entertained by this you don't have to read the stories, just apt-get upgrade and enjoy the software. This is the way things work in the world of Free software, as Linus says [apcmag.com]: 'May the best code win!' If you want a kernel developed by boring, outsourced workers: choose Microsoft.

Re:more important things

[Hatta]

There isn't much more important work for a kernel than improving performance under load. They could probably do better by focusing on I/O scheduling than CPU scheduling. My CPU spends an inordinate amount of time waiting for IO. But kernel performance is of the utmost importance to kernel developers. What does it matter if it runs on your hardware if it doesn't run well?

Re:Can someone provide some insight?

[recoiledsnake]

CFS won not because it was a better scheduler at the time, but because Inglo worked with the developers to make it better, instead of fighting everyone who questioned anything about it.

That was certainly not how I read it when it happened. I came off with the impression that Kolivas was ripped off of his ideas by Inglo and that Linus was wrong in brushing Inglo off and going with Inglo.

The LKML email linked reinforces my suspicion. Habits and attitudes don't die easily. We see ANOTHER guy complaining that his patch was half bakedly ripped off with no explanations whatsoever and a tangential acknowledgement.

FOSS projects are about helping everyone, and listening to new Ideas. Something Kolvias was having a hard time doing.

Did you even read the linked email? Inglo seems to be talking in patches and with no discussion. If something were to happen to him or if he quits due to any reason, there would be no one who would understand the code and the features behind it enough to maintain it.

Re:Can someone provide some insight?

[Opportunist]

Folks? Could we concentrate on creating a good system instead of egos?

You know, this really has a lot of the Life of Brian. "This is his gourd", "No, we'll follow his sandal".

The nice thing about Linux is that we can actually choose which one we prefer. Put both into the distributions and let the people sort it out. The better one will prevail.

Re:Already suggested

[tinkerghost]

Potentially dangerous to allow "anyone" to do it... it would be much better to have some type of ACL that allows specific users/group and/or perhaps specific programs to be reniced outside of root's control.

The principle is that Skype/Kphone/FPS register themselves with a 'loader' type function requesting a nice level of -10 at install. Daemons that don't care about latency can register themselves as +10. Anything that doesn't care, doesn't register.

Since only Root should be able to perform a systemwide install & consequentially have access to the 'loader', Root would be determining the runlevel, but any user can use it. If the program were installed locally by a non-Root user, then it wouldn't be able to access the 'loader' to configure it & would run normally at nice 0.

The current model, limits any normal user to nice 0 and above, with everything defaulting to 0. Lets face it, most daemons aren't time sensative enough to require a nice of 0 - the 10mS difference in mounting the CD is totally overwhelmed by the 2 seconds it takes the tray to close & the disk to spin up anyway - a perfect candidate for a nice of 10.

On the other side of the coin, dropping Skype or Kphone into nice 0 is bad. As audio systems, pretty much any delay is a recipee for poor audio quality. They need control when they need it - not 10mS later. The same with GUIs, because they directly interact with people, they need to have the snappy response of a negative nice program - not as negative as multimedia, but better than the baseline.

Re:Can someone provide some insight?

[cartman]

I was recently reminded of how badly Linux sucks when I went over some old code I'd written to get the CPU name and speed. The FreeBSD and OpenBSD implementations of this code each called a single sysctl for each result.

There are good reasons for exposing cpu info (and other kinds of OS data) as files, rather than gathering that data through system calls. Exposing the data as files makes that data usable to the range of tools people use on an OS (Unix) that supposedly treats everything as files. The data can be grepped, piped, opened, run through 'sed', cut, awked, etc. Exposing OS-internal data as files is done for the same reason that RDBMSes expose internal data as tables, and for the same reason that XML schema are XML documents themselves (this is why people complained about DTDs--they weren't XML).

Linux did not invent this idea. The inventors of Unix (Thompson and Ritchie) came up with the idea of exposing internal OS data as files, which they considered a natural extension of the Unix philosophy of treating everything as files.

You may disagree with it, or you may not be familiar with all the arguments for and against it. However you should refrain from just concluding that "LINUX SUCKS" because something was not the way you expected.

Whether the data should be exposed through files is an arguable point. It's not an area in which BSD is clearly factually superior. My own opinion is that gathering that data through files is better.

Re:Can someone provide some insight?

[Anonymous Coward]

Would it be so hard to expose the data as files and also provide sys calls to retrieve the information as well. In the worse case the sys calls could just read and parse the files for you. It would make changes to those files be considered more judiciously and also document how to parse them.

Re:Can someone provide some insight?

[rbanffy]

The scheduler has nothing to do with security exploits. This will only distribute cycles more evenly. Additionally the ideal malware should take steps to prevent it from getting too much CPU time in order to avoid detection.

Re: Can someone provide some insight?

[Dolda2000]

I was recently reminded of how badly Linux sucks when I went over some old code I'd written to get the CPU name and speed. The FreeBSD and OpenBSD implementations of this code each called a single sysctl for each result. The Linux version had to read /proc/cpuinfo and parse it.

While I agree with you that Linux seems almost pathetic compared to BSD when under heavy load, I have to object to that reason for calling the *BSDs superior to Linux. In fact, the sysctl interface is the single most bothering thing about the *BSDs to me. Isn't the treatment of everything as a file the very core of the Unix philosophy? It may be true that files like /proc/cpuinfo could very well be made easier to parse, but I find nothing to complain about with e.g. the /proc/sys/ tree, or, for that matter, sysfs. Requiring a special syscall just to fetch kernel data that could just as well be made available through the file system is, in my mind, just ugly for a Unix system, and I can only imagine that it is done that way for historical reasons.

In almost any other way, however, I would prefer the *BSDs over Linux. I still run Linux, though, but that's mainly because I want to keep running Kerberized NFS. :) When FreeBSD implements that, I may well switch.

Re:Can someone provide some insight?

[ciroknight]

PlugSched would have let us do this in a big way, letting us change at boot or even while the system is running what cpu scheduler is working. But, most distributions pull most of their code from the Mainline and Linus' blessed code, so it's unlikely any distribution will ever see Kolivas' scheduler in action to know whether or not it could do better than Ingo's bastard-clone.

Now we get even more people questioning Ingo's code, and instead of examining the code, we get people starting to question Roman's merits too. The personal attacks over this need to stop, and we need to look at the actual problem instead of looking at the developers who are questioning the choices. I personally hope Kolivas will come back to the kernel and hasn't moved on for good, just needing some time away from the hot-heads and their corporate Linux eccentricity. Desktop Linux needs to start at the Kernel and end at the user, no component between left behind.

Re:Can someone provide some insight?

[Cajal]

Of course, the parent poster wasn't just complaining that Linux exposes this information as files rather than via sysctl. The real problem is that the format of the information changes frequently, and varies between platforms. /proc/cpuinfo, for example, varies widely between x86, ppc and sparc.

It's exactly this sort of inattention to detail that makes me not enjoy developing on Linux.

Re:BEOS scheduler?

[norkakn]

Yeah, but how was it as a LAMP stack?

Re:Can someone provide some insight?

[martin-boundary]

Indeed. There are known discussions. These are discussions we know that we know. There are known undiscussions. That is to say, there are discussions that we know that we don't know. But there are also unknown undiscussions. These are discussions we don't know we don't know. They occur a lot on slashdot.

Re:Fairness is relative...

[ultranova]

On a personal workstation, however, an interactive user doesn't necessarily want all the programs to have fair access... we typically would like to have what we're concentrating on currently to be more responsive (have potentially unfair access) or else we may see dropped frames, stuttering music, or the like because the scheduler is trying to be fair to applications that aren't interactive with the console user.

This is where priority levels, or "nice", come in. They allow the user to tell the computer which stuff should be preferred/unpreferred, and how much.

Unfortunately, some people insist that the scheduler should guesstimate the priorities by itself, rather than depending on the user's judgement; since the scheduler can't read the mind of the user, such guesstimating (or "heuristic") scheduler frequently guesses wrong, leading to performance problems. What's even worse is that the constantly changing "dynamic priority" for every program can easily lead to temporary high latency, which in turn leads to audio/video skips and unresponsive system.

A totally fair scheduler will give each process CPU time according to their nice level, without trying to guesstimate. Con Kolivas came up with such a design (the Staircase Deadline scheduler), after which Ingo Molnar wrote a similar design (the CFS) based on the SD which then got accepted into the kernel. Con wasn't happy about this and quit kernel development altogether, which is unfortunate since the "-ck" patchset maintained by him was/is a huge improvement over the vanilla kernel.

Re:Can someone provide some insight?

[Jah-Wren Ryel]

I think it should be trivial to have a kernel switch activated on boot to set the preferred scheduler. This way, 3D gamers would be happy to set the -ks (I fail to remember its correct name) while the rest of us would be happy to leave it alone and get the CFS. Maybe by having a modular scheduler architecture would allow to have kernels with the -openvz or -oraclesbest or whatever other schedulers one may want (and could get support from the kernel developers).

I don't know one thing about how PlugSched was implemented, but other unices like HPUX have the ability to designate that certain cpus will run under specific schedulers. So you can run straight FIFO scheduler on one pair of cpus, a real-time scheduler on another set of cpus and the normal unix scheduler on the rest. You need to combine that with a way to bind processes to those cpus to get the benefit of the different schedulers, but that almost goes without saying.

I'm kind of surprised that linux does not support that sort of thing already, with SGI's heavy use of linux on their NUMA altix systems, I would have thought that support for multiple simultaneous schedulers would already be in the mainline.

Re:Can someone provide some insight?

[drsmithy]

Err...only slightly. Unix based operating systems separate user space from the rest of the system. Nothing much can be done without root access.

Pretty much everything malware might want to do, it can do without elevated privileges.

Installing Malware on a Unix system is, for this reason virtually impossible.

It's as simple as convincing an end user to execute a program with elevated privileges. Which is only marginally more difficult than convincing them to run a program at all. Which isn't particularly difficult.

MA large user base is often used as a rationalization for windows malware, but in reality it is just an incorrect excuse.

It's not an "excuse", it's an inescapable aspect of the "malware problem".

Re:Can someone provide some insight?

[marcosdumay]

"The explanation that this is a way to steer the development toward a single scheduler that should function well enough for everyone, desktop, embedded or server, works for me."

Ok, so the scheduler must be perfectly fair, priorizing no process, so servers work well. Must give priority to IO bound processes, so desktop users feel the system smoot. And shouldn't be configurable, to not penalize the resource constrained embebed systems.

Let me add that it should give priority entirely for time constrained processes and never reschedule processes, so it can be used for real time. Of course, it should reschedule processes periodicaly, so desktop users won't need to wait CPU bound processes to end before they are able to move their mouse.

There you have, your ultimate process shceduler. Seems quite doable.