Debating the Linux Process Scheduler 232
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."
Can someone provide some insight? (Score:5, Interesting)
Re:Can someone provide some insight? (Score:5, Funny)
That's not the Slashdot way. We're supposed to have an unfounded opinion based on insufficient facts and preexisting prejudices.
Re: (Score:3, Insightful)
Re:Can someone provide some insight? (Score:5, Informative)
It's possible for programs right now to exploit how the current schedule dishes out time. As far as I know, they currently only do so out of ignorance, rather than malice. The new scheduler just corrects the problem.
It's not something a user can really see unless they know exactly what they are looking for, and unless a dev/admin has a program that's behaving unfairly, it's not really going to matter to them, either.
There is another invisible effect as well... Kolivas apparently publicly announced his decision to stop working on the kernel, which would include the current scheduler. That means finding another maintainer for his code, should any problems surface. If you've got 2 pieces of code that test the same in speed (as they do according to some), and 1 has a dev that's willing to keep working on it, and the other doesn't... Which would you pick?
The new code also has the added advantage of being a really really neat idea, which encourages people to work on it as well.
Re:Can someone provide some insight? (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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 particularl
Re:Can someone provide some insight? (Score:5, Informative)
Wow, not even a full year has past and we're already getting revisionist historians trying to change the situation.
Kolivas quit because of the scheduler debacle, because nobody would listen to Kolivas but were apt to follow Linus and his cronie Ingo around when they drum up more-or-less the exact same thing. Instead of critically listening to Kolivas' points, Linus and Ingo attacked Kolivas' merits. Under that kind of personal attack, I couldn't say I wouldn't have quit just to shut them up. Not all of us are stubborn mules and jackasses.
Re:Can someone provide some insight? (Score:5, Informative)
Revisionist history is working both ways I see. Whenever Linux or another kernel developer would bring up a point of failure in Kolvias's scheduler instead of Fixing the problem Kolvias would lash out and say it wasn't broken.
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. FOSS projects are about helping everyone, and listening to new Ideas. Something Kolvias was having a hard time doing.
That is at least how i read the whole debate.
Re:Can someone provide some insight? (Score:5, Interesting)
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.
I believe Linus was the claiming Ingo worked better with the developers (or at least I saw him write to that effect on the LKML). By contrast, Kolivas had many individuals helping out with his branch who were quite pleased with his progress.
The problem is that Kolivas was working to help desktop, and particularly 3D game users. He'd say it wasn't broken if it was optimizing for those particular platforms at a cost of a fraction of a percent Oracle performance. Most of the kernel devs don't care 2 cents about 3D or desktop users, and many are employed by large enterprise businesses, so you can see who won.
Personally I think Kolivas should've been given full access to merge his code. Many of us found his work very useful and it's sad to see him driven away by a few people who are oblivious to what everyday users need. Even if his scheduler was not the default one, it still would've been nice to have as a mainline kernel option.
- SEAL
Re:Can someone provide some insight? (Score:5, Interesting)
I don't know for sure, but 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).
A slightly more clever approach would be to let one switch schedulers on the fly, but I think it's asking too much.
Re:Can someone provide some insight? (Score:5, Informative)
Re:Can someone provide some insight? (Score:4, Informative)
Of course, Linus and Ingo rejected those patches as well.
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
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
Re:Can someone provide some insight? (Score:4, Insightful)
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.
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.
Given you both can't seem to get Ingo's name right (Score:3, Informative)
Re: (Score:3, Insightful)
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: (Score:3, Insightful)
Now we get even more people questioning Ingo's code, and instead of examining the code, we get people starting to question Roman's
Re: (Score:3, Interesting)
Re:Can someone provide some insight? (Score:5, Interesting)
I don't think that's really fair. Average these days actually has a large spread. Average web user? Average game player? Average video watcher? Average musician? Averaging what? And that's the point of the CFS. Each of those users have different expectations and each reflect a different type of scheduler workload. The old scheduler has lots and lots of code to handle various performance problems for corner cases for each type of "average user" depicted above. This in turn means the code is hard to read, hard to understand, and even harder to maintain. Worse, some code which help some corner cases actually make things worse for others. This in turn means more special case coding and even more complex testing.
The CFS is designed to simplify most everything the O(1) schedule does without tons of complex heuristics and special code to address various corner cases. In other words, in stead of trying to guess what you really want, the CFS simply tries to be as fair as possible for everyone, thusly ensuring many categories of corner cases are simply no longer an issue with the CFS.
This does not mean CFS is always better than O(1), but early results indicate they are traveling down a good road. In fact, the last round of patches I read about, actually establish CFS ~12% faster then the old O(1) schedule. Of course, it's yet to be seen how well it will be received and how quickly it will prove it self with a large user base. The devil is in the details with schedulers and sometimes real world user workloads don't reflect anything which has been tested/validating during development.
Nonetheless, development on CFS continues and it certainly is providing hope it will be smaller, faster, provide lower latency, be easier to maintain, and address a wider range of workloads, including many corner cases, without requiring complex code to track and analyze heuristics.
Long story short, yes, if all goes well, even the average user may notice an improvement depending on the particulars of their workload. Wouldn't you notice a more responsive desktop?
Re:Can someone provide some insight? (Score:5, Interesting)
It's largely a drastic improvement over the old scheduling mechanisms that Linux has relied on, although other OSes have largely worked through such problems some time ago.
While it's not exactly THE most scientific, I had a few rounds of testing over which did better on load vs. things still behaving exactly the way they should. I ran all of them with audio playing through KDE artsd, video player, glxgears, etc, loaded, plus inducing a CPU load via 'stress'. Linux, even with CFS, it's still fairly easy to 'upset' it by just producing a fairly large (2-4) amount of load. Solaris did notably better. While it seemed to have a few quirks with scheduling in general, it could sustain a load of around 8-12 without producing video/audio frame drops. FreeBSD, with the experimental SCHED_ULE 2.0 scheduler (as of March 2007) could sustain a load of over 80 with no problems, frame drops, or even glxgears slowing down to a complete crawl (although you wouldn't want to especially use OpenGL at such, it was still getting the speed of software glxgears), and even at 120+ load, the mouse wouldn't respond, while everything else kept going fine. This seems purely useless, but it really comes in handy if trying to do one or more KDE compiles while watching video, on Linux, this tends to be prevented. For the uninitiated, load averages like that are basically a multiplier vs. how much actual work your computer can do in real time. Eg, a 0.5 load would mean you're doing 50% of what you could in realtime. A 2.0 load means you're trying to handle twice what you can do in realtime, it is weighted against how many processors you have (I have one), but other things like disk access can also contribute to the load average, depending on OS.
So, longer story short, a superior CPU scheduler can make a world of difference in how things behave when your system's something else with the CPU(s) at the same time.
Re: (Score:2)
Re:Can someone provide some insight? (Score:5, Interesting)
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
It's exactly this sort of inattention to detail that makes me not enjoy developing on Linux.
Re: Can someone provide some insight? (Score:4, Insightful)
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: (Score:2)
Take his comments with a grain of salt. You can safely and completely ignore his comments about worst case latency because they are meaningless. In the Linux kernel, worst case latency almost always is caused by device drivers. Besides, most people have no idea how to properly measure worst case latency...and the measurement method may not reflect a real world workload in any meaningful way.
Depending on the devices you
Re: (Score:3, Funny)
The same reason as windows: hardware support.
Re: (Score:2)
Back then, skipping sound happened just by dragging windows around. In 2.6.22, the only time I've had that happen is when something else in my system went berserk and ate all my ram+swap up, or a full-on crash.
Re: (Score:3, Interesting)
Re: (Score:2, Interesting)
Object lesson:
Re: (Score:2)
I mean, why shouldn't it? Things like audio skipping while compiling simply happen because one or a few processes are given more time for the sake of throughput while "starving" other
Re: (Score:3, Informative)
The new scheduler will make those values behave more like they're supposed to relative to one another, and hopefully use fewer resources for itself in doing so.
Re:Can someone provide some insight? (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
Already suggested (Score:2)
Re: (Score:2)
The advantage of that is that launching with preset negative nice numbers could be done by anyone rather than only by the superuser. That would show some benefits for interactive/latency sensative software without creating any problems for software that doesn't report a need - they would still default to 0.
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. Back when I was in college, it was typical to PPP in and then telnet to some machine in the CS lab there to get work done. Someone would be sitting at the physical terminal and we might have 3 or 4 other users logged in on the machine doing some coding or whatever. If those other 3 users could renice s
Re: (Score:3, Insightful)
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 i
fairness and interactivity (Score:2)
Also, nice levels are more predictable. In general, decreasing the nice level by one means that the task gets 1.25 times as much cpu. This means that a nice -19 task gets approximately 50x the cpu time as a nice 20 task.
Re:Can someone provide some insight? (Score:4, Interesting)
There have long been tricks like "interactive priority boost" or "nice -10 X" that attempt to make the desktop more responsive, and media play smoothly. But others believe those are just tricks, bound to misbehave in corner cases, and that a good scheduler and well implemented priority scheme will do just as well without the drawbacks. That's where CFS is trying to be. In particular most desktop responsiveness is of the sort, "I need a little CPU, and I need it NOW!" while compiles and such are "I need lots of CPU, and I'll take it whenever I can get it." The CFS keeps track of not just who's using a timeslice, but how much time they're using. That way, those short bursts of CPU keep their priority intact, while more CPU-intensive processes tend to get some priority degradation.
This goes back a little farther than Ingo Molnar's current involvement. A while back, Con Kolivas began putting in a bunch of work on the scheduler trying to get desktop response to work right, essentially he wanted his media, and his compiles, too. He did a lot of work and attracted a lot of users and fanbois along the way. More recently, Ingo Molnar get interested too, and came up with the "Completely Fair Scheduler." When it came time to pick one, Linus saw the CFS doing pretty well, still under heavy and active development. CK's scheduler was also pretty good, but the fanbois poisoned the waters, insisting that it was perfect as it was, and didn't need fixing. Linux chose an active development model over "perfection." Unfortunately Con Kolivas felt slighted in the process, and left. IIRC, he may have been absent during the decision window, and his fanbois did him in.
Add to all of this the fact that the kernel can now run tickless, so that laptops can really scale back their power in between keystrokes or while you're reading the screen. There has been quite a bit of interesting work on scheduling, lately.
Re: (Score:2)
When it came time to pick one, Linus saw the CFS doing pretty well, still under heavy and active development.
No, that's not really what happened. Based on my reading of the list at time, Linus had already decided to use CFS from the time it first was published.
Two things happened that were very misleading. The first was the initial CFS announcement. It appeared at the time, that at the same time that Ingo was being highly critical of SD, he was implementing a variant behind everyone's back. This wasn't true; I have no reason to doubt his words that he did throw together the first version in a day or so of ha
Re: (Score:3, Informative)
Average user? Multimedia tasks will not skip or stutter while the system is under load. The opposite of Vista's network performance taking a nose dive while playing MP3s, Linux systems with the new scheduler will see little/no impact from background/n
In a blind taste test.... (Score:4, Insightful)
Re:In a blind taste test.... (Score:5, Interesting)
With Windows, how does this work? I will never know for sure. if MS doesn't choose to make it known, it isn't known. If they choose to make it known, then I just have to trust they are telling the truth (Windows Update anyone).
With a project like this, you are much more likely to get the best approach to the situation.
Re: (Score:2)
Should be "very little experience with Linux". You would think Slashdot would have a 'preview' to help with this
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
On the other hand, I have always liked the scheduler when it came to high-load and not too latency critical situations, even though IMHO the FreeBSD scheduler still scales better.
Esoteric Discussions (Score:5, Insightful)
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: (Score:3, Informative)
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?
Someone (Con Kolivas?) suggested a "pluggable" scheduler API. I think this was even backed up by patches to provide this functionality. Linus Torvalds rejected the proposal - I think he said that the benefits would be outweighed by the need to maintain multiple schedulers. My opinion is that the kernel could have inc
Re: (Score:2)
ISTR, the actual issue was the overhead needed to put the scheduler in an API instead of in the kernel was unacceptably high. That said, there are modules for compiling in the different schedulers.
It's been stated a couple of places that the different schedulers have different strengths & weaknesses
Re: (Score:3, Interesting)
For those who wonder, default schedulers under Solaris 10 include TS (Timeshare, the default), IA (Interactive), FSS (Fair share scheduler, workload management), RT (Real Time), FX (Fixed) an
Re: (Score:2)
Re: (Score:2)
I think most people notice when their computer starts to lag, skip frames and audio tracks, etc. They may not be able to identify this as a scheduling problem, but they do notice.
Re: (Score:2)
Re: (Score:2, Informative)
I doubt any of us could tell the difference. Storm in a tea cup.
I probably could. But then again, I do a lot of realtime audio recording and editing and therefore I make use of Ingo Molnar's REALTIME and PREEMPT kernel scheduler patches.
The standard scheduler, without those patches, is just about completely useless for realtime audio recording and editing, even with nothing more than the necessary apps, JACK, X, a lightweight window manager (openbox), HAL, syslogd, anacron, and 6 gettys running. Even taken anacron out of the situation didn't help.
I think there was a TV show about this (Score:3, Funny)
Re: (Score:2)
On next weeks show, Linus' returned from the dead, evil twin hatches a devious plot to turn kernel design discussions into a nerd-culture flame war. Tune in to see what happens next!
That was actually quite fun. Thanks. (Score:2)
Re: (Score:3, Insightful)
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. T
Still don't understand the fixation (Score:2, Insightful)
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 fire
Re: (Score:2)
A) Important.
and
B) Possible for them to fix.
Why you'd want a scheduler guy to work on IO performance is completely beyond me. Might as well have a janitor cook dinner for you.
Re: (Score:2)
That is why its a big deal. Many developers have loyalities to one of the process scheduler develoepers.
So in other news its drama
Re: (Score:2)
Re: (Score:3, Informative)
All of this started with Roman doing a code review of CFS a month or two ago. Roman asked some questions to clarify what certain parts of the code were doing, Ingo asked Roman to provide more info so he could see where CFS was falling short on Roman's test cases. Both sides kept trying to talk passed each other. Eventually, Roman got frustrated and provide
Re: (Score:2)
Just fork it (Score:2)
Ugh bring back 2.7 please (Score:5, Insightful)
Oh well. I guess I'm just getting cranky in my "old" age.
Re: (Score:2)
Many commerical developers have steered clear of linux and supported Windows and Solaris for this reason. Oracle even has a script that will make their rdms refuse to run if any modifications are made on a stock rhles installation. Binary and abi compatibility is important as Microsoft knows.
Yes there are changes like this but it wont break apps or a huge way linux works. 2.6 is likely to be permanen
Re:Ugh bring back 2.7 please (Score:5, Informative)
This doenst seem to me to be ripped every 6 months, unless the 2.6 tree is just about 6 months older...
Re: (Score:2)
Re: (Score:2)
If you want a stable kernel, don't use the vanilla kernel. Linus has repeated stated that a perfect kernel is not the goal with his tree. His goal is to promote the development of the kernel which maintains some sense of stability but he pretty much guarantees that it will not be perfect.
The process of creating a bugless kernel requires that all new development stop for an extended period of time. Which is what happe
Did the Open Source is about choise 6 (Score:2, Insightful)
Re: (Score:2)
More importantly, however, this requires a stable "scheduler API". Not all schedulers want to hook the same things, which means that you need to add (and maintain) a superset of the hooks required by all the various schedulers.
Finally, anyone who cares enough to be replacing their scheduler should be technically advanced enough to apply a patch and recompile the kernel.
Re: (Score:2)
Flamewars are usual in developer websites (Score:3, Insightful)
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.
Why wait? (Score:2)
BEOS scheduler? (Score:3, Interesting)
Re: (Score:3, Insightful)
The Geek wars have a new topic (Score:2)
-Emacs vs. vi
-Reiderfs vs. ext3 (obsolete)
-GPLv3 vs GPLv2
-GPL vs BSD
and now:
Scheduler wars!
Keep pushing upward (Score:2)
There is a good reason for this. When you want to make something stable, you want to take proven ideas and refine them so you can make guarantees.
But for our hacker souls, and our inner adventurers, we also need something that is determined to break new ground and make no guarantees. The CFS is being justified b
Scheduler Question for the /. Experts (Score:4, Interesting)
One way to cause dramatic performance problems on a Windows machine is to simply write a program that accesses lots of files. Performing a network backup with the Windows Networking API is a good example of this. Windows responds by fetching the files from disk and using system memory as a cache. In the process, the working set of programs running on the computer is paged out. The result is that low-priority activities can dramatically slow down potentially important activities on the computer. A good example of this is doing a network backup or a background virus scan on a Windows computer while trying to do any foreground activity (like browsing the web or using Microsoft Word).
So far, in my experience, Linux seems pretty immune to these priority inversions. Will the new scheduling algorithms allow low-priority processes to cause priority inversions by abusing non-processor resources like the network or disk drives?
CFS issues - some bugs to iron out before 2.6.23 (Score:3, Informative)
Beyond the heated discussion with Roman Zippel, there are still a few workloads which can trigger regressions, one of which I found running some unit tests.
This is covered in this thread [kerneltrap.org], and although there is now a version of CFS which does not exhibit the problem (see graph of combo3-yield patch [devloop.org.uk]) it is not the one that is meant to be merged in 2.6.23 (these patches are 2.6.24 material) so Ingo is getting me to test patches until this regression can be solved.
One slightly annoying thing is that the current fix involves using sysctl to switch back (at least partially) to the old scheduler mechanism!
Linus, it's second time (Score:2)
that Ingo takes the work/ideas of others about the scheduler and presents his own implementation without proper reconnaisance or collaboration.
As the main responsable of the kernel, don't you think that something has to be done? At the current state I (as a developer) would not try to contribute to such a personally 'monopolized' project, that's sad.
Gross mis-characterizations of Molnar (Score:4, Informative)
As I started reading the comments on here I noticed that many were quick to down Ingo for his transgressions and its quite obvious from the comments that no one has bothered to read the exchange on LKML in order to become familiar with what is going on. I have read it, I have 0 bias for either Zippel or Molnar and I can say without any reservation that Zippel is a wank and Molnar is borderline saintly.
A recap of what I have read and understood about the entire situation:
Ultimately I think Zippel is purposefully trying to provoke Molnar throughout all of this. His wild accusations are nothing more than games that he is playing, the guy has a chip on his shoulder and if Linux was my toy, I would have blocked him from the mailing lists.
Re:Snooze (Score:5, Funny)
Re: (Score:2, Insightful)
Re:Snooze (Score:4, Interesting)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Maybe it would take a kernel guy 5 min to write the code?
Re: (Score:2)
Apples and oranges. The expertise and information needed to write a process scheduler has absolutely nothing in common with the expertise and information needed to write a device driver, specially if the problem pertaining to the lack of device drivers for that particular class of hardware is, as you know, the complete absence of information on the hardware itself or even how the hardware wa
No, there aren't. This is what a kernel DOES. (Score:3, Informative)
I'll ignore for a moment the fact that you're essentially making the same argument as "Why aren't all scientists (from solid-state physicists to cognitive neuroscientists) working on a cure for cancer instead of [perceived frivolous research in the news]?" You're ignoring the different kinds of expertise that go into a complex field of work like kernel development.
Instead, I'm just going to foc
Re:more important things (Score:5, Insightful)
Re: (Score:2)
Basically they are replacing the spark plugs when they could be switching to an electric engine. A huge amount of overhead comes from system calls, context switches, and data copying -- three things that effectively cannot be eliminated if the system runs unsafe code. You can *sometimes* eliminate data copying in specific cases using shared memory or complex operations (sendfile), but not normally.
I just changed the spark plugs, oil/oil filter and air filter in my truck. Mind giving me and installing an electric engine to put in it? After all, I know how to work on gasoline engines but I've never done work with electric engines so you're forcing me to deprecate my current abilities and knowledge to spend a considerable amount of time and money changing to a new paradigm for something that has more long term potential but will, at least in the short term, be less maintainable and will cause me signif
There is no debate (Score:2)
Re: (Score:3, Insightful)
This is where priority levels, or "nice", come in. They allow the user to tell the computer