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

Article is misleading

[RailGunner]

Funny, in the article those framerates for Quake III show CFS beating the pants off of SD.

Besides, the biggest barrier to 3d games in Linux is video card drivers (ATI, I'm looking at you!) as 3D drivers in Linux, even the proprietary ones, have tended to be unstable.

Linus is right one this one, the scheduler is a small part.

Re:Article is misleading

[Omnifarious]

FPS is a poor measure of the feel of a game. I know it's what all the graphics card benchmarks use, and it does do a good job of measuring the total processor and video card throughput, but that's not the most important thing.

The most important thing is the time between you pressing a key and the changed game state being reflected on your screen and how consistent that delay is.

One of the arguments that CK has made about kernel development is that kernel developers have become obsessed with throughput to the exclusion of all else and that this leads to very poor desktop performance because throughput is a poor measure of 'interactivity'. Someone posting 3D game framerates as evidence of one scheduler being better than another is exhibiting exactly this bias.

IMHO latency is a better measure, but still not perfect and it can be hard to measure in some cases.

I don't know enough about the scheduler to know which one is better or which one exhibits particular properties. But I can see that the throughput bias is evidenced in force in the thread the article points to.

And CK is also right that big iron shops care more about overall throughput than any measure of 'interactivity'. IMHO there ought to be some kind of pluggable scheduler system that allows you to completely change the algorithm to reflect the preferred behavior of the computer you're using.

Re:Article is misleading

[Anonymous Coward]

You are on to something here. CK uses arrays and has a lower context switch time whereas CFS uses red-black trees. What this means is that doing a bunch of "while :; do done" loops that always use their full timeslice is a test that favors CFS as much as possible really.

As an aside, what kind of retard benchmarks a scheduler using a game that is doing nothing and 100% cpu tasks? Put some disk access in there, maybe a set of folders that will easily fit in cache and then find . them. Have some fixed-seed random busy / sleeps of different ratios. Have the game play a demo reel on repeat and record avg *and* min/max fps. Come on Ingo must be somewhat familiar with CK so he must know that these tests where CK is roughly the same are biased toward CFS to begin with. If you are going to say 'look I did these benchmarks and it's a wash' and use that as a justification then at least do good benchmarks.

I think this more than anything else confirms my impression than Ingo is just hacking shit until it kinda works ok. Note that this is exactly the same kind of rationale Linus gave for diss'ing Con so flame off.

You won't get good games until you get marketshare

[nweaver]

This is irrelevant to the gaming front.

The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?

Thus you will only get games where the developer has gone out of their way to ensure complete portibility and provides a port mostly out of courtousy.

The scheduler details are irrelevant for this: what Linux Games need is 10%+ marketshare on the desktop.

Strange, I've been gaming in Linux for years.

[DaedalusHKX]

I have Windows XP and Gentoo Linux running side by side, and strangely, Gentoo scores 10 to 12 FPS faster in World of Warcraft, Warcraft III and even Doom 3. Granted they are commercial games, but if they can run in WINE that fast, I wonder what a direct Linux implementation would do. I just love seeing folks buying the headlines instead of blazing their own paths.

That's why the world is in the shape its in... the majority is always waiting for someone to save the day. You want desktop Linux? Then make it your desktop. Otherwise stop bitching and post some valid comments.

The X Factor

[mcelrath]

I keep wondering...X is a single threaded server, communicating with a (generally) single threaded game. Worse, wine inserts the wineserver process, so I have three single threaded things trying to synchronize to get interactivity. A low latency event like a keypress might require all three processes to be scheduled in succession, to get a response on the screen. A poor man's way to do this is with the kernel's scheduler, but a far superior way to do it is to have multiple threads in the X server. Scheduling an interactive event isn't hard. Getting crap on the screen in the same scheduling timeslice is hard (impossible?) since it requires a second scheduling point. As I understand, this is how BeOS achieved substantial interactivity in the presence of load -- my having a multi-threaded graphics server *and* kernel.

So, how much can be gained by rewriting X, or going to a different graphics server? Or do I completely misunderstand the effect of X?

-- Bob

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