Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Debating the Linux Process Scheduler

Zonk posted more than 6 years ago | from the little-from-column-a-little-from-column-b dept.

Programming 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."

cancel ×

232 comments

THIS FP WAS POSTED BY THE LINUX PROCESS SCHEDULER. (0, Funny)

Anonymous Coward | more than 6 years ago | (#20604621)



   

Re:THIS FP WAS POSTED BY THE LINUX PROCESS SCHEDUL (0)

Anonymous Coward | more than 6 years ago | (#20604647)

Don't you mean "processor"?

Impressive... (0)

Anonymous Coward | more than 6 years ago | (#20604943)

That was quite a round robin way to do it...

Can someone provide some insight? (5, Interesting)

Opportunist (166417) | more than 6 years ago | (#20604637)

Is someone who does understand the differences able to explain, in non-kernel-developer terms, what the big differences will be for the average user, developer or administrator? I mean, I'd love to discuss it, but first of all I'd want to know what we're discussing.

Re:Can someone provide some insight? (5, Funny)

Jeff DeMaagd (2015) | more than 6 years ago | (#20604811)

I'd love to discuss it, but first of all I'd want to know what we're discussing.

That's not the Slashdot way. We're supposed to have an unfounded opinion based on insufficient facts and preexisting prejudices.

Re:Can someone provide some insight? (4, Informative)

Aladrin (926209) | more than 6 years ago | (#20604865)

Average? Probably nothing. But for devs/admins that are worried about certain processes taking more time than others, it -should- be more fair and keep things running smoother.

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? (4, Insightful)

Opportunist (166417) | more than 6 years ago | (#20605259)

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:Can someone provide some insight? (1)

the_B0fh (208483) | more than 6 years ago | (#20605595)

I don't know, and don't care about the schedulers, but that last bit is a bit... disingenuous. The only reason Kolivas stopped working on his scheduler is because his was kicked out.

Re:Can someone provide some insight? (5, Informative)

ciroknight (601098) | more than 6 years ago | (#20605629)

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?

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? (4, Informative)

peragrin (659227) | more than 6 years ago | (#20605933)

What goes around comes around.

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? (0)

Anonymous Coward | more than 6 years ago | (#20606007)

Speaking of revising history, you're doing a pretty good job of that yourself.

Re:Can someone provide some insight? (1)

Nosklo (815041) | more than 6 years ago | (#20604869)

what the big differences will be for the average user, developer or administrator?
I guess we must wait until it is out so we can test and benchmark both options.

Re:Can someone provide some insight? (1)

poetmatt (793785) | more than 6 years ago | (#20605003)

From what I understand (correct me if I'm wrong), its a rewrite to how the kernel handles process thread priority and resources [wikipedia.org] , something that was an issue before. Not intentionally but certain programs would put themselves far above where was needed or something.
Made little to no effect on anything because it wasn't a huge change, it was a huge forum debate but more of a small thing (like deciding to use 91 octane instead of 89 in a car - this is not even remotely a life or death situation). Obviously changing this priority could improve or degreade performance randomly depending on the processor and program run, but it's unlikely that it's going to make a huge difference on the performance of a program in the first place. This is in comparison to the previous scheduler [wikipedia.org]

Re:Can someone provide some insight? (5, Interesting)

Zephiris (788562) | more than 6 years ago | (#20605013)

Essentially, the difference is how well processor resources are divided up, how evenly, and how big the pieces are each process or task gets. Most anyone who has used Linux has had the dreaded moment where you're trying to multitask a bit, and are compiling a program while listening to music, or waching a video, and then...that's terrific, video frames are dropped, or the audio skips. Even if intermitant, it's quite annoying, at the very least. The 'Completely Fair Scheduler' is an attempt to have more fair, sane, and generally less complex scheduling. This also happens to reduces the worst case latencies, averaging from (at least on the tests with my computer) 120+ms on vanilla 2.6.22 scheduler, to ~2.6ms with CFS.

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:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605179)

...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...
I'm calling bullshit on that one.

Re:Can someone provide some insight? (2, Interesting)

Anonymous Coward | more than 6 years ago | (#20605233)

Typical Linux response. Usually it's Linus that calls bullshit, then other people discover it's true, then Linux appropriates it, and acts like it invented it.

Object lesson: /dev/poll. Linus ranted about how Solaris must have "cheated", then mysteriously the same architecture appears in Linux less than a year later.

Re:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605417)

Okay, a load of 1-2 locks up the Linux kernel, Solaris, can do 8-10, and FreeBSD, an open source, lets see how this works, can copy into linux, etc. can pull off 80 to 120? That makes complete sense. So sorry for doubting an unattributed "study" posted on Slashdot.

I just ran a test on my machine, and I can model the entire atmosphere at the particle level, with complete environmental data, as well as random occurrences of something that I like to call "The God Effect", Break RSA encryption, and watch "Cars" DVD in realtime.

BULLSHIT!

Re:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605617)

I just ran a test on my machine, and I can model the entire atmosphere at the particle level, with complete environmental data, as well as random occurrences of something that I like to call "The God Effect", Break RSA encryption, and watch "Cars" DVD in realtime.
And I can watch "Cars" being rendered in realtime while doing all this.

Re:Can someone provide some insight? (1)

heelrod (124784) | more than 6 years ago | (#20605391)

Bullshit on you dude. You got anything to back that up?

Re:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605567)

Apparently as much as the O/P does...

Re:Can someone provide some insight? (1)

Hatta (162192) | more than 6 years ago | (#20605291)

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.


Well damn. That's just... embarassing. Why's everyone using linux if it sucks so much?

Re:Can someone provide some insight? (4, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#20605897)

Well damn. That's just... embarassing
It's more embarrassing than the grandparent states, actually. ULE 2 has been improved a lot in the last few months, and the newer ULE 3 performs a lot better, particularly on SMP systems. From what I've seen, the new Linux scheduler has roughly the same shape (and size) performance curves on 1-8 CPU systems as the old 4BSD scheduler that ULE replaces.

Why's everyone using linux if it sucks so much?
Because Linux sounds cool, while BSD sounds geeky. 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. Actually, it had to parse it in two different ways, because it turns out the format of cpuinfo is different on x86 and all other platforms. Reading the battery life was even worse. On FreeBSD it's just a matter of reading the hw.acpi.battery.life sysctl (one line of code). For Linux, it involves parsing some messy procfs stuff with a format that has a habit of changing between releases. I don't understand how a developer could prefer Linux to any other UNIX.

Re:Can someone provide some insight? (1)

Ant P. (974313) | more than 6 years ago | (#20605763)

I haven't bothered testing it with numbers, but I've definitely noticed the improvements since 2.6.0.
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:Can someone provide some insight? (2, Informative)

FauxPasIII (75900) | more than 6 years ago | (#20605061)

Each process running on Linux has a "niceness" value which you as the user can set. The value indicates which ones you want to have more access to CPU power. The numbers range from 19, meaning roughly "only use the CPU when noone else needs it", to -20 meaning "all your CPU are belong to it".

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? (1)

MajinBlayze (942250) | more than 6 years ago | (#20605519)

The interesting thing that seems to be missing from the distribution packagers is that everythin comes defaulted to the same nice level, even if you are running a "desktop" distro or "server" distro. It seems that it would make sense to set up some default nice values (or even a profile-like setup) that could assign priority to where it would be noticed the most (i.e. media, desktop interactiveness).

Re:Can someone provide some insight? (1)

berashith (222128) | more than 6 years ago | (#20605609)

But then no one would be willing to pay me to do it.

Already suggested (1)

tinkerghost (944862) | more than 6 years ago | (#20605735)

back when the scheduler issue first popped up there were a few suggestions about developing a method to preset nice levels for software - IE, kphone & skype could be niced to -10 & most daemons to 10 with a start rather than having to reset them after launch with 'renice'. 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.

Re:Already suggested (1)

phantomlord (38815) | more than 6 years ago | (#20605901)

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 some buggy, or perhaps deliberately malicious, code and deny everyone else the ability to do anything significant with the machine, it would be a problem. Factor in, as well, at one point, we were learning about distributed computing and were running things like distributed fractals across the entire lab. I can only imagine the fun as 2-3 people (or maybe 30) attempt to run their distributed fractal at -20 across the entire lab .

Re:Can someone provide some insight? (4, Interesting)

mamer (536310) | more than 6 years ago | (#20605669)

Another question: I've been waiting for OpenMP support in gcc, it seems to be coming soon. In the meantime, I tried to parallelize my code by hard coding my threads using pthreads. I tested it by running several matrix-matrix multiplications "in parallel" on a multi-core CPU, and what I've got was all threads running on the same processor. Only after increasing my number of threads to a couple of dozens, I get some of them to run on the second processor. So basically, I am not getting any performance gain. I asked a number of people an they tell me "this is an old problem, basically the Linux kernel scheduler is stupid and nobody has bothered to fix it". Now, is Ingo's new scheduler fixing this? if gcc-openmp relies on the kernel scheduler, should we expect that open-mp will basically work-but-not-really-work on shared memory multi processor machines? I think this is an important issue to address, especially in an era where high-performace computing has become the driving force behind the hardware. BTW, how are otehr commercial compilers overcoming this scheduling problem?

Re:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605797)

25% Funny, 25% Insightful, 25% Informative, 25% Troll
and 25% incorrect math.

fairness and interactivity (1)

Chirs (87576) | more than 6 years ago | (#20605171)

The big user-visible difference are improved fairness and interactivity. If you have multiple tasks sharing a cpu, the amount of cpu time allocated to each task is better regulated.

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? (3, Interesting)

dpilot (134227) | more than 6 years ago | (#20605585)

Do you want your media to play without skips or drops while you're compiling your new kernel?

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:Can someone provide some insight? (0)

Anonymous Coward | more than 6 years ago | (#20605637)

The average person with a below average PC will have a slightly better experience. This is work to improve interactivity (Mouse jumpiness).... I know with old hardware and windows, music can get choppy because extra packets arrive on the ethernet. That sort of thing is pretty ugly.

The scheduler is important and I think in general people will have a slightly better desktop experience. On fast hardware, you probably wouldn't really notice.

Re:Can someone provide some insight? (2, Informative)

WhiteWolf666 (145211) | more than 6 years ago | (#20605879)

Average developer or administrator? Your system will be more "stable" under heavy loads, with fewer/no processes starved for CPU cycled. The new scheduler (building on Kovilas work in an unfriendly fashion) better divides up processor time among multiple tasks.

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/normal operations on their gaming, music, and video. Your mouse won't skip around while the system is loaded, and responsiveness will remain high except in situations involving super-heavy I/O usage (I/O starvation is more difficult to solve than CPU starvation).

It actually makes a substantial difference, and the system is much more fun to use.

There are some informal test results [kerneltrap.org] (LKML) from kernel trap:

here's an update: checking whether Wine could be a factor in your
problem i just tested latest CFS against latest SD with a 3D game
running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the
most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41).
Here are the results in a pretty graph:
      http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg [redhat.com]
or, in text

2.6.22-ck1 2.6.22-cfs-v19
quake + 0 loops 41 fps quake + 0 loops 41 fps
quake + 1 loop 3 fps quake + 1 loop 41 fps
quake + 2 loops 2 fps quake + 2 loops 32 fps
quake + 3 loops 1 fps quake + 3 loops 24 fps
quake + 4 loops 0 fps quake + 4 loops 20 fps
quake + 5 loops 0 fps quake + 5 loops 16 fps
Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively
during any kind of load. The game is completely unusable with 1 CPU loop
running already!

Quake3-under-Wine behavior under CFS: framerate goes down gently with
load, gameplay remains smooth. Framerate is still pretty acceptable and
the game is playable even with a 500% CPU overload. The graph looks good
and the framerate reduction goes roughly along the expected 1/n
'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps
its fully 41 fps even with 1 competing loop running on the CPU due to
"sleeper fairness".]

Expected debate (0)

Miltazar (1100457) | more than 6 years ago | (#20604645)

Expected Debate: For-Molnar: Its better! Against: No its not, its totally unfair. For: No, its a fair scheduler, and its better! Against: Nuh-uh! Your a liar*hits him* For: I'm telling Linus!

There is no debate (1)

SpaceLifeForm (228190) | more than 6 years ago | (#20605619)

Real world benchmarks will decide.

In a blind taste test.... (3, Insightful)

budword (680846) | more than 6 years ago | (#20604673)

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

Re:In a blind taste test.... (0)

Anonymous Coward | more than 6 years ago | (#20604845)

And besides, what is this crap? A story on Slashdot actually related to something significant in Geekdom? NO WAY! I want to here more justification for IP piracy!

Re:In a blind taste test.... (0)

Anonymous Coward | more than 6 years ago | (#20605029)

Someone stole your IP Address?

Re:In a blind taste test.... (4, Interesting)

MyLongNickName (822545) | more than 6 years ago | (#20604867)

As a windows user who has very little experience with Windows: This is one of the strengths of open source. if you have a large enough base of contributors, these "little" details are brought out into the open, and you can really understand how things work. I've read a bit on the subject, and it is interesting to see the different approaches that can be taken to something that most of us do not even think about.

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:In a blind taste test.... (1)

MyLongNickName (822545) | more than 6 years ago | (#20604899)

As a windows user who has very little experience with Windows

Should be "very little experience with Linux". You would think Slashdot would have a 'preview' to help with this :) Sheesh :)

Re:In a blind taste test.... (2, Funny)

peterpi (585134) | more than 6 years ago | (#20604953)

It could help stop you forgetting to close your 'i' tag too! :p

Re:In a blind taste test.... (1)

samkass (174571) | more than 6 years ago | (#20605811)

I see your argument, but the facts don't seem to actually back it up. By many benchmarks, Linux is currently worse than almost all the closed-source schedulers at handling loads greater than 2.0 on an interactive system and has been for years. The CFS patches seem to mostly close the gap, but I haven't seen many argue it will make Linux better than the alternatives, just let it at least play in the big league ballpark.

Esoteric Discussions (4, Insightful)

Archangel Michael (180766) | more than 6 years ago | (#20604939)

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:Esoteric Discussions (2, Informative)

LizardKing (5245) | more than 6 years ago | (#20605107)

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 included a single scheduler in the kernel.org tarballs, but by providing the pluggable API it would lower the bar for those who wish to develop or play with different schedulers.

Re:Esoteric Discussions (1)

tinkerghost (944862) | more than 6 years ago | (#20605869)

Someone (Con Kolivas?) suggested a "pluggable" scheduler API. [snip] Linus Torvalds rejected the proposal - I think he said that the benefits would be outweighed by the need to maintain multiple schedulers.
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 and the differences are mostly seen on fringe cases where your specific need will probably dictate which one is best for you anyway.

Re:Esoteric Discussions (1)

huckamania (533052) | more than 6 years ago | (#20605645)

"most people aren't going to notice"

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:Esoteric Discussions (1)

zojas (530814) | more than 6 years ago | (#20605731)

the big concern is that the current scheduler is great for big servers, but totally sucks for desktop systems. using the old scheduler on my core2 duo system with 3 gb ram, I get crappy response from gui apps if heavy disk io is running in the background. that to me seems completely ridiculous, and in fact the kernel developers should be downright embarrassed by that situation!! I'm hoping the new scheduler will be better. (to be fair, part of the blame lies with the developers of the bloated gui apps, but still! my system should be ridiculously overpowered, and it doesn't seem to be)

Re:In a blind taste test.... (2, Informative)

morgan_greywolf (835522) | more than 6 years ago | (#20605441)

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.

Re:In a blind taste test.... (0)

Anonymous Coward | more than 6 years ago | (#20605871)

Hot dog in a hallway.

Re:In a blind taste test.... (1)

DohnJoe (900898) | more than 6 years ago | (#20606029)

actually, whenever I load amazon.com in firefox, my mp3 player (xmms) will temporarily stop playing (2.6.18 on debian etch).
h So I, for one, would welcome our new completely fair scheduling overlords, if it can fix this annoyance!

I might even be tempted to trying my own kernel again, it's been a while since I've done that...

I think there was a TV show about this (2, Funny)

RightSaidFred99 (874576) | more than 6 years ago | (#20604683)

When Nerds Attack 3: The Nerdening.

More like... (0)

Anonymous Coward | more than 6 years ago | (#20604781)

Nerd Attack 2: Electric Boogaloo

Re:I think there was a TV show about this (1)

Azarael (896715) | more than 6 years ago | (#20605615)

What I wonder, is which scheduler they will use to pick a programming slot for the soap opera that someone is apparently trying to produce..

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!

Re:I think there was a TV show about this (0)

Anonymous Coward | more than 6 years ago | (#20605649)

In my best Jedi VOICE and hand wave 'This is not the site you are looking for. I think the site you are looking for is called Digg'

Typo? (0)

Anonymous Coward | more than 6 years ago | (#20604727)

New process scheduler? Not processor.

Snooze (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#20604731)

Seriously has Slashdot got such a boner for Linux that they'll post absolutely every fucking little boring thing they find?

Re:Snooze (4, Funny)

Reason58 (775044) | more than 6 years ago | (#20604785)

Seriously has Slashdot got such a boner for Linux that they'll post absolutely every fucking little boring thing they find?
You must be new here.

Re:Snooze (0, Flamebait)

stonedcat (80201) | more than 6 years ago | (#20604897)

GP must be a Mac fanboi.

Re:Snooze (2, Insightful)

EricR86 (1144023) | more than 6 years ago | (#20605085)

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.

Re:Snooze (3, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#20605953)

Maybe I missed them, but where were all of the Slashdot articles about the ULE 2 and ULE 3 FreeBSD schedulers? From all the benchmarks I've seen, they make the Linux scheduler look embarrassingly antiquated (performance characteristics matching the 4BSD scheduler that ULE was originally designed to replace).

Re:Snooze (1)

monkeySauce (562927) | more than 6 years ago | (#20605075)

Well, we've got to get boners for something, and girls are too elusive.

Re:Snooze (0)

Anonymous Coward | more than 6 years ago | (#20605125)

the upper management of slashdot is such a bunch of losers. we know. i wish they'd start thinning out the herd and get some real talent in here.

let this flamewar die already (0)

Anonymous Coward | more than 6 years ago | (#20604749)

It's been beaten to death everywhere else already.
Some improvements have been identified for 2.6.24

more important things (1, Insightful)

LM741N (258038) | more than 6 years ago | (#20604771)

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)

Re:more important things (2, Informative)

Chirs (87576) | more than 6 years ago | (#20604971)

Have you considered the fact that different people work on different areas of the kernel? The people that work on the scheduler generally have very little to do with hardware drivers.

Re:more important things (1)

LM741N (258038) | more than 6 years ago | (#20606053)

Yes, I understand that people have different interests. Actually I should have been more specific. My frustration comes out as I don't understand why all these distros expect you to go in and hack the system just to get wpa-supplicant working.
Maybe it would take a kernel guy 5 min to write the code?

Re:more important things (0)

0xABADC0DA (867955) | more than 6 years ago | (#20605117)

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 recently found this paper [am-utils.org] which claims:
  * 20%-80% performance by the compiler placing parameters in a shared memory so the kernel does not have to copy data
  * 60-80% from doing multiple calls as one (ie, readdir-stat, open-read-close)
  * 40-90% from putting some parts of the app logic in the kernel even with safety checks inserted into the code

This suggests that the average overhead of say 1.5x from Java code running in the kernel over C code would be dwarfed by the inefficiencies of actually running that C code safely. This is the kind of thing they should be working on.

Re:more important things (1)

phantomlord (38815) | more than 6 years ago | (#20605589)

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 significant pain (by not having a vehicle to drive) until I get it all installed just right.

Someone who is good writing a compiler may not be good at creating a new kernel design. Someone who is great at writing a window manager may not be great at creating a new cryptography algorithm.

Last time I saw, Linus was pretty open to taking patches... the bar you have to meet is that the patches need to be understandable by him (and thus maintainable) and that he thinks it will improve the kernel more than hurt it. If you have patches, submit them (or convince the person who did write them to submit them) and persuade Linus. If you don't have patches, pay someone to write them for you or at least convince (but don't berate) a kernel developer of the merits of your idea so they will write them for you. Don't, however, expect a kernel dev to go off on a tangent that is going to require large amounts of the kernel, some of which he may not have any interest in, to be replaced just because you think it might be a good idea. That's like expecting a government to completely dissolve its defense system because someone got the idea that everyone would be more relaxed if they got a free massage every week.

Re:more important things (1)

GreatBunzinni (642500) | more than 6 years ago | (#20605561)

I know its not easy getting info on wireless chips, but time would be better spent working on something like that.

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 was done in the first place.

No, there aren't. This is what a kernel DOES. (2, Informative)

Valdrax (32670) | more than 6 years ago | (#20605611)

I know its not easy getting info on wireless chips, but time would be better spent working on something like that.

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 focus on your assertion that support for a few more wireless chipsets than the abundant choices we have today is more important than fixing problems in the most central and fundamental task of the kernel -- a task that even the most minimalist microkernels consider necessary to put into the microkernel.

This is simply hogwash. Scheduling affects every single part of the system, and it's a major factor in the perceived and real performance of a system. Fixes to the scheduler will affect how a user enjoys their system over the entire life of the system whereas a missing wireless driver affects them once -- at purchase time.

Furthermore, not all Linux systems have wireless networking. Adding more wireless drivers is going to be useless in nearly all server and most embedded uses. You seem to be under the mistaken impression that the purpose of Linux is to provide a good desktop or laptop experience. There are considerably more application domains that Linux operates in.

And frankly...

Just look at all the live CD's out there and how many can connect to wifi? Ubuntu and not much else.

This is not the kernel developers' problem. They've provided the functionality as evidenced by the fact that Ubuntu can do it. This is up to the distro developers to work on. Again, you make the mistake of assuming that all developers are equal and interchangeable and that they all have the same responsibilities in bringing the product to you, the unpaying customer.

Re:more important things (4, Insightful)

Hatta (162192) | more than 6 years ago | (#20605745)

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?

just give me round robin.... (0)

Anonymous Coward | more than 6 years ago | (#20604793)

.... and call it a day.

Not interesting at all. (-1, Troll)

Anonymous Coward | more than 6 years ago | (#20604875)

"It will be interesting to see how the new processor really performs when the 2.6.23 kernel is released"

No, it will not. 99.9% of people will not notice or care.

That was actually quite fun. Thanks. (1)

ishmalius (153450) | more than 6 years ago | (#20604913)

That was a very entertaining read. I love it when strong personalities squabble, and egos collide. Open Source is Fun!

Re:That was actually quite fun. Thanks. (1)

HoboCop (987492) | more than 6 years ago | (#20604947)

I was not entertained. What a bunch of babies.

Re:That was actually quite fun. Thanks. (2, Insightful)

jeevesbond (1066726) | more than 6 years ago | (#20605333)

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:That was actually quite fun. Thanks. (1)

Climate Shill (1039098) | more than 6 years ago | (#20605697)

To me all the flaming and arguing, [...] means that the kernel developers are passionate about what they do.

They're passionate alright. Passionate about preventing anyone outside the inner clique from touching "their" kernel.

It means that, once the dust settles, we'll get a superior product.

...by making it clear that anyone who has a superior idea will be told to fuck off, and have their idea reimplemented badly by someone pretending it was theirs.

as Linus says 'May the best code win!'

What staggering hypocricy.

Still don't understand the fixation (2, Insightful)

Anonymous Coward | more than 6 years ago | (#20604931)

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.]

Re:Still don't understand the fixation (1)

Aladrin (926209) | more than 6 years ago | (#20605123)

Because they care. What else do they need? An individual developer doesn't care what you, or anyone else wants. They work on what they think is

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:Still don't understand the fixation (1)

Billly Gates (198444) | more than 6 years ago | (#20605211)

The flamewar is based on drama between 2 waring linux developers. One is accusing the other of being Linuses favorite and stealing algorithms and ideas with the different schedulers. I think the other developer quit linux alltogether as a result.

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:Still don't understand the fixation (1)

Ant P. (974313) | more than 6 years ago | (#20605659)

No, that was Con Kolivas. The new guy this time around seems to have appeared out of nowhere claiming to have some far better scheduler implementation than the CFS one that's been in development for months, but is being a complete dick to everyone else.

Re:Still don't understand the fixation (1)

gmack (197796) | more than 6 years ago | (#20605513)

For 7372 the fix is to use a better designed filesystem such as XFS. As far as I know there are people dedicated to trying to fix ext3's inefficiancies but for the most part people who want better performance are just switching to other filesystems.

Re:Still don't understand the fixation (1)

DirkGently (32794) | more than 6 years ago | (#20605885)

Did you actaully read through those bug reports? The problem is CFQ. Choose a different one. Unlike the CPU schedulers, the IO schedulers *are* pluggable. Try anticipatory or deadline.

Just fork it (1)

zymano (581466) | more than 6 years ago | (#20604973)

And find out which ones better.

Re:Just fork it (0)

Anonymous Coward | more than 6 years ago | (#20605723)

Con's SD scheduler started like that, separately from the main linux development. He was heavily criticized, until a scheduler based on the same basic concepts was written from scratch (~72h) and merged, despite SD's years of testing.

Linus himself criticized him because his development went on on a separate mailing list.

It seems to me that forking would mean condemning his work to irrelevance.

This is how OSS works. In the end, the maintainer decides what's merged, what's not merged and what he himself rewrites to merge it as his work - inspired by others.

Misleading title.... (0)

Anonymous Coward | more than 6 years ago | (#20605005)

Although they mention improvements and the like, it seems like "Flamewar involving Linux Process Scheduler personalities +BONUS shreds of Linux Process Scheduler Goodness" would be much more appropriate.

Ugh bring back 2.7 please (4, Insightful)

maelstrom (638) | more than 6 years ago | (#20605197)

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.

Re:Ugh bring back 2.7 please (1)

Billly Gates (198444) | more than 6 years ago | (#20605385)

The reason behind this according to an interview with Linus is that he wanted to stabilize a common codebase.

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 permanent unless a real overhaul or change is needed (like maybe rewriting for gpl v3).

Small incremental improvements serve everyone better and make less development time. It took years for a total switch from 2.4 to 2.6.

Re:Ugh bring back 2.7 please (5, Informative)

luciofm (844395) | more than 6 years ago | (#20605575)

There was the 2.4 schuduler, the old O(1) 2.6 scheduler and now the new 2.6 CFS scheduler...
This doenst seem to me to be ripped every 6 months, unless the 2.6 tree is just about 6 months older...

Well, if you can't win an argument on merit... (0)

Anonymous Coward | more than 6 years ago | (#20605253)

a number of other Linux developers have stood up to defend Molnar and call into question the motives of the complaints
In other words, a number of other Linux developers have resorted to ad hominem attacks on the voices of dissent.

Did the Open Source is about choise 6 (2, Insightful)

denisbergeron (197036) | more than 6 years ago | (#20605255)

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

Re:Did the Open Source is about choise 6 (1)

Chirs (87576) | more than 6 years ago | (#20605563)

Because then every function call becomes an indirect call, causing performance penalties.

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:Did the Open Source is about choise 6 (1)

TheRaven64 (641858) | more than 6 years ago | (#20606055)

Depends on how it's done. FreeBSD supports two schedulers, but you have to make the choice at compile time. There is no overhead, because it's just a matter of compiling one set of scheduler functions instead of the other. The linker then sorts it all out for you. Xen, in contrast, uses an extra layer of indirection, since it allows schedulers to be chosen at boot time. I believe Solaris uses a mechanism similar to Xen, although it might do some runtime patching.

Flamewars are usual in developer websites (2, Insightful)

Spy der Mann (805235) | more than 6 years ago | (#20605257)

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.

Why wait? (1)

ruiner13 (527499) | more than 6 years ago | (#20605347)

It will be interesting to see how the new processor really performs when the 2.6.23 kernel is released."
Why would you have to wait? Couldn't someone just grab the source, compile it, and benchmark it? Yes, it may have bugs, but it should at least give an indication of overall speed.

Too much backing (0)

Anonymous Coward | more than 6 years ago | (#20605373)

Let's just hope Roman Zippel does not throw the towel like Con Kolivas just because everyone thinks Ingo Molnar's scheduler math is always the best to back him.

BEOS scheduler? (2, Interesting)

Danathar (267989) | more than 6 years ago | (#20605451)

Does anybody know what kind of scheduler BEOS used before it's demise? I seem to recall it ran circles around other OS's at the time when it came to multitasking multimedia.

The Geek wars have a new topic (1)

drolli (522659) | more than 6 years ago | (#20605791)


-Emacs vs. vi
-Reiderfs vs. ext3 (obsolete)
-GPLv3 vs GPLv2
-GPL vs BSD ....

and now:

Scheduler wars!

Keep pushing upward (1)

athloi (1075845) | more than 6 years ago | (#20605909)

It may be time for Linux development to split. One fork will focus on stable code that works like a UNIX, and the other in forging new boundaries. I think the FreeBSD developers did something simple.

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 by performance, or administrative reasons, but why not focus instead on the real reason we'd like to see it happen?

It's a cool idea to play with.

We're primates. Play is how we learn and invent. Keep pushing upward, making the code do new things and taking on new challenges, because the hacker spirit is play. That playfulness has brought us most of our thinking outside the box, good inventions. Keep it up. Aim for the stars.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...