The Completely Fair Scheduler's Impact On Games 315
eldavojohn writes "We've heard a bit about the completely fair scheduler previously, but now Kernel Trap looks at the implications this new scheduler has for 3D games in Linux. Linus Torvalds noted, 'I don't think any scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends up being not one or the other, but somewhere in between. But at the same time, no technical decision is ever written in stone. It's all a balancing act. I've replaced the scheduler before, I'm 100% sure we'll replace it again. Schedulers are actually not at all that important in the end: they are a very very small detail in the kernel.' The posts that follow the brief article, reveal that Linus seems quite confident that he made the right choice in his decision to merge CFS with the Linux kernel. One thing's for certain, gaming on Linux can't suffer any more setbacks or it may be many years before we see FOSS games rival the commercial world."
FOSS games (Score:3, Informative)
Multiple choice schedulers (Score:2, Informative)
Re:Article is misleading (Score:5, Informative)
I agree to some extent. Notably the test specified in the article is "open a game and then sit there without hitting the keyboard." In my mind, this means the game isn't responding to any I/O, so gets pushed to the background, so adding more tasks just means it gets 1/tasks timeslices. Seems reasonable. I'm not sure why the CFS would keep the game running more often than SD if there was no I/O. An interesting comparison would be to see not only the FPS/CPU usage for the game but also for the "loop" tasks. (Those tasks also are not I/O bound.)
Fundamentally I think the name CFS is a little bit odd - how does one define "fair"? In fact, I probably don't want my scheduler to be fair at all - I want it to run the stuff I want fast, and the other stuff it can run slow. That's not very fair.
So, I would say there is not enough information given in the article to tell exactly why the systems had different FPS performance for different schedulers - just looking at that number doesn't tell how it's splitting the time among all the processes.
Re:Modular Kernel GREAT QUESTION jshriverWVU (Score:4, Informative)
Anyways, you can still just apply Con's patch to the kernel to use his scheduler instead of the old scheduler (and if he keeps maintaining it, you'll be able to use SD instead of CFS). Don't forget that we haven't even had a kernel released using CFS!
Re:Article is misleading (Score:5, Informative)
Fair, in this context, means that the scheduler will give all the running tasks CPU time in proportion to their priority (nice level). It follows from this that all the tasks in a given nice level are given equal amount of CPU time, and a higher-priority task (lower nice level) is given more CPU time than a lower-priority one.
SD scheduler (but not CFK, AFAIK) also had idle priority, which means a task that only runs if nothing else at any nice level wants to run. Very useful for running FoldingAtHome.
That's what "nice" is for. A fair scheduler respects nice levels, as stated above.
Re:Article is misleading (Score:2, Informative)
I think you're thinking of the IO scheduler, which you can select at compile time. The CPU scheduler is not a choice--you must apply a patch and change the kernel's source for that. And while distros do extensively customize compilation options, the patches that they apply are generally small (besides Gentoo, which is very proud of the patchset it applies to its kernels). For almost any distro, it would be too much work to support multiple kernels (where one is based on unmaintained code).
Re:Pluggable (Score:5, Informative)
Re:Article is misleading (Score:5, Informative)
A fair scheduler basically times the actual CPU usage. It starts timing when it gives control to the process, and stops timing when the process yields or the scheduler decides to interrupt the process. it tracks processes not by ticks but by actual time used. (This post is based on my understanding of the issue. I may be incorrect.)
Re:Strange, I've been gaming in Linux for years. (Score:3, Informative)
Wine really isn't an emulator, so there shouldn't be that much overhead.
Re:Strange, I've been gaming in Linux for years. (Score:3, Informative)
Lots of the development tools built into the doom3 executable didn't work at all under Linux, either. Not sure if they did under Wine at day 0, or if they do at all today.
Re:Strange, I've been gaming in Linux for years. (Score:5, Informative)
Re:Article is misleading (Score:3, Informative)
In part, yes, but for some things, it doesn't go all the way.
For instance, Windows will give either the foreground application and/or programs the scheduler things are interactive a priority boost. (I forget exactly what it does.) In theory, this means that the program you're working with at the time gets the attention. It's conceptually like a window manager renicing the processes you're working with when you change focus.
I don't know if it actually makes a difference. It can also cause problems if a program can fool the scheduler into thinking it's interactive, because then it will get a bigger time slice than the priority says it should allow.
There *are* other ways to do scheduling besides just adjusting the nice level.
Re:Article is misleading (Score:4, Informative)
In w2k at 125hz other players would appear to be moving smoothly. In redhat they would have a constant stutter, like the other players positions were only being updated every 2 or 3 frames, rather than every frame as they appeared to on w2k. This made a difference when playing the game, I ended up moving around distros until I found the preemptive, and low latency patches made the stuttering go away.
For me, fps wasn't ever the problem. It was something else.
Re:Strange, I've been gaming in Linux for years. (Score:5, Informative)
A perfectly reasonable question, but the answer may well be "about the same". The NE in wiNE istands for "Not an Emulator". In a sense, WINE *IS* a native Linux graphics implementation albeit aided or hindered by using the Windows API interfaces. If I recall the WINE documentation correctly it says that WINE is sometimes faster than Windows on the same hardware and application and sometimes slower.
Here's a link http://linuxhelp.blogspot.com/2006/02/wine-vs-wind ows-xp-benchmarks.html [blogspot.com] that seems to say roughly the same thing.
Re:Article is misleading (Score:3, Informative)
Re:Article is misleading (Score:3, Informative)
Re:Strange, I've been gaming in Linux for years. (Score:2, Informative)
The post which originally claimed it was "hypocritical" only mentioned Linux, and not FOSS. It's perfectly possible for someone to like and use Linux, and not care about the Free software philosophy; in the same way it's perfectly possible for someone to use Firefox on Windows because they prefer it to MSIE or Opera, and don't care that it's Free. There's absolutely nothing hypocritical about that. It's also not hypocritical to prefer or even "believe in" Free software, but be willing to use proprietary software when it's the best choice (that'd be pragmatism). It's not even hypocritical to do that, while still hoping for (or helping to create) a Free alternative to the proprietary software. But, you already know that (unless you actually don't have any idea what the word hypocritical means).
Secondly, it isn't necessarily illegal to make an "emulator" (which WINE isn't, technically, although it's used like an emulator would be) for the Win32 API. After all, there is a commercial entity (Cedega or something?) involved in WINE, and they haven't been sued into oblivion; presumably, if they were actually doing something illegal, they would have been shut down. I mention this as a commercial example because it's feasible some companies wouldn't bother trying to stop technically illegal activities carried out by free software people, on the grounds of it being too difficult a target. Businesses are another matter.
Even your apparent claim that the PC games market wouldn't exist if it weren't for Windows is absolute bunk. Games existed before Windows and on various platforms. If the PC OS market wasn't so heavily dominated by Microsoft, but instead had fairly even splits between 3 or 4 different platforms, then PC games would routinely be designed cross-platform and released across all major platforms. Not doing so would be stupid. There's nothing magical about Windows which allows it to run games. It's purely market share that results in developers ignoring other PC platforms, just like some developers choose to develop for a specific console. Market shares are subject to change.
Overall, I'd rate your troll about a 7. Not a bad effort at all.