The Completely Fair Scheduler's Impact On Games

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

Comments

Re:Article is misleading

[ThosLives]

Neither the summary nor the FA did a great job of summarizing the issues.

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:Article is misleading

[ultranova]

Fundamentally I think the name CFS is a little bit odd - how does one define "fair"?

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.

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.

That's what "nice" is for. A fair scheduler respects nice levels, as stated above.

Re:Pluggable

[andrewd18]

Linus has already explained why he doesn't like the idea of a pluggable scheduler system. See http://kerneltrap.org/node/14019

Re:Article is misleading

[Tacvek]

All schedulers attempt to do that. However the old scheduler design collected statistics based on what process was running at each clock tick. So if a process always yielded right before the clock tick the scheduler would mark it as having used 0 ticks worth of clock time. So it would always stay near the top of the list, and could monopolize the CPU.

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.

[Nasarius]

WOW DO have native linux ports

Uh...no. WoW does run nicely under Wine, but that's not a port.

Re:Article is misleading

[Muzzarelli]

I made the switch from w2k to redhat v8 or 9 about the time that XP came out. At the time I a serious q3 player practising about 5-6 hours a day, playing in leagues, etc. One thing everybody playing did was lower their resolution and raise the refresh rate up to 120 or 125hz, you get smoother view of the game. In both operating systems my machine would easily sustain the 125fps you need in q3, but there were subtle differences in the game.

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.

[vtcodger]

*** I wonder what a direct Linux implementation would do***

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 that seems to say roughly the same thing.