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."
Article is misleading (Score:5, Insightful)
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 (Score:5, Insightful)
Why not just say that, instead of trying to get a bunch of
Re: (Score:3, Insightful)
It's nice to see the commentary from the mailing list, but without a decent explanation of the situation, the posting isn't informative to many people.
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: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: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: (Score:3, Informative)
Re: (Score:2)
Me too confused.
Re: (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
Re: (Score:2)
I'm gonna guess it worked tho...
hehe, 9 users and 2243 guests online
Re: (Score:3, Funny)
*bad-dum* *crash!*
Re: (Score:2)
Or nice for that matter.
Re:Article is misleading (Score:4, Insightful)
Re: (Score:2)
Re:Article is misleading (Score:5, Insightful)
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 (Score:5, Insightful)
And actually, If people think this is a problem, Distro's already heavily customize the kernels so switching this out in their particular kernel shouldn't be much of a problem.
Re: (Score:2, Informative)
I believe that you can swap the scheduler out. I might require you to rebuild the kernel but there is nothing stopping a distro, you or anyone else from using a different scheduler.
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: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Re:Article is misleading (Score:5, Insightful)
Re:Article is misleading (Score:5, Interesting)
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.
Re:Article is misleading (Score:5, Interesting)
I would think that the biggest barrier to 3d games in Linux would be the inherent paradox concerning the lack of 3d games.
No gamers = No profit for game companies = No games being produced.
No games = No gamers = No profit for game companies.
The one thing that I would agree on is that video card support brings game developers and gamers closer to a certain extent. Having better drivers might get both gamers and developers to consider Linux a *little* more. However, even if Linux had terrific video card drivers that were just as good or better than the Windows drivers I still wouldn't consider Linux for games just because there's very few good games available.
Better drivers can only help. But I can't consider that the "biggest" problem. The biggest problem is that there are too few people who use Linux. So video card manufacturers don't care about Linux. Game developers don't care about Linux and lastly (most) gamers don't care about Linux.
I realize there was a lot of bad management decisions involved, but look at what happened to the last company that tried to make a business out of porting titles to Linux (*cough* Loki *cough). I have just about every Loki title that was developed and I really wish they had stayed afloat. Maybe it was bad business decisions and maybe it was just that there was no profit in porting titles to Linux. The situation might be different today and I hope that someone has the desire, balls and money to step up and try what Loki tried 7 or 8 years ago. But Loki's fate did send a clear message. There's no profit in Linux games. John Carmack also said back then that releasing Q3A for Linux saw no profit.
Hopefully as more desktop companies, like Dell, jump on board and push Linux then maybe both the game developers and video card manufacturers will start to see the potential for profit and a result gamers will jump on board. But even Mac has suffered from the same problem for 20 years, and there's way more profit in developing for Mac than Linux. And it shows. There are more commercial Mac games than there are Linux. But both Linux and Mac have next to no games at all when you compare to the titles available for Windows.
Re: (Score:3, Insightful)
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.
FOSS games (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Maybe I'm wrong again, but making those high poly models isn't easy either.
Re: (Score:2)
Re: (Score:2)
That's not to say that there are not a lot of
Re: (Score:2)
Re: (Score:2)
The first thing you get asked when trying to apply for a position as an artist is to show them some of your work. Which is kinda hard if you never participated in any project. And to get a project, they first of all want to see some of your work...
Re: (Score:2)
Re:FOSS games (Score:4, Insightful)
Are you saying all of "Snow White" was drawn by one person? All 24 fps, 83 minutes worth?
Re: (Score:2)
Bad example. The team of animators on Snow White and the Seven Dwarves was managed to an unprecedented degree, with an obsession for consistency and quality control. This is not the sort of thing you get from hobbyist contributions.
Coders are a dime a dozen, minus the dime. Modelers, sketch artists, musicians, and actors are the fellas you're just not going to easily get on a FOSS project.
Re: (Score:2)
Control can be maintained, even in FOSS projects.
Answer: Project Peach (Score:3, Interesting)
Yes, the blenderheads are at it again, and they are doing a game this time...
Re: (Score:3, Interesting)
All those fruits...
Re: (Score:2)
Also, Art has a very specific purpose in mind. It can't be reused easily. Where else are the 7 dwarves going to be used other than Snow White?
Software algorithms can be reused for all sorts of things.
Re:FOSS games (Score:4, Interesting)
Of course they're in the minority. For them, there's nothing to be gained in providing their services for free.
The publicity for working on games is almost nonexistent. For example, can you, name any artist that worked on any one of the most popular games? I can, but I know a bunch of artists that work in the games industry.
Besides, artwork doesn't work as FOSS. Unlike code, artwork for games isn't inherently "sharable" - it's designed for the purposes of that game and that game only. Game engines can be used for multiple different kinds of game. Artwork almost always can't. It may be used for sequels (but generally isn't as the requirements change from game to game) but it can't be used across different types of games.
Re: (Score:2)
You know a bunch of artists, and I have to assume that you have some ties to the game industry. Now, how many IT security researchers do you know? Probably a few, if that. Doesn't matter though. They don't care if you know them, as long as people who're in the IT sec biz know them, know their name and know their value. You won't hire t
Re: (Score:2)
I really don't think that's fair or accurate for either programming or art. A lot of artists give away at least some of their work on the Internet, and a lot of programmers don't do that. Whether it's more prevalent in one field or another, that's a question that can't be definitively answe
Re: (Score:2)
Creating free for a game means:
a) It needs to be a set, often of considerable size
b) It's usually set by the developers what you need to create
c) You have to create it with the game's restrictions
d) They all need to be consistent in style
In short, it's not free experimentation or creativity. I imagine the average art designer-inspiring-to-be-artist would rather create art than designing up a large set of resonably similar graphics - to
Isn't going to happen, period! (Score:2, Insightful)
Re:FOSS games (Score:4, Insightful)
I always wondered why they just wouldn't contribute at least some early works to the open source community? Is it maybe just the lack of a good website where stuff like this could be indexed or isn't there a good enough standard license model to release something like that for free? I thought the Creatice Commons license [creativecommons.org] would be quite suitabel for it.
Everybody who spent some time finding a good textured and rigged low-poly character model, preferably with basic animations, on the net for use in an open source game, knows that there is next to nothing available. Well, at least not when I could have needed one about two years ago.
It really doesn't have to be that professional or finished - even that untextured rat someone made a decade ago to have something to shoot at, later to replaced by some creatures, could maybe be of use to someone; and if he textures it, and maybe do a simple animation and perhaps record some sounds, and then uses it in his project, he should give the additional stuff he made to other developers as well.
Soon there will be a nice looking 3D rat with some textures to choose from, various sounds, walking and death animations, etc. and everybody did his part. That's the open source way - why does it seem it's not very common among artits and only coders?
Anyway, I think it could be really just the right website that is missing - some Sourceforge-style page with a nice upload-frontend, where stuff gets properly indexed based on categories, tags and styles and with a feedback option, where contributers can see which projects are using their works. Add some voting to rank it, karma, apply a fair license to it upon upload and I think something like this could really take off.
You won't get good games until you get marketshare (Score:5, Insightful)
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.
Re:You won't get good games until you get marketsh (Score:4, Insightful)
To get Market Share you need games.
To get Games you need Market Share.
Re: (Score:2)
Re: (Score:2)
They might be cross-platform but they still cost 100's of 1000's of dollars to license. Game Engines top some of the most expensive proprietary software out there.
Moreso it is false to say "most major games" (my emphasis) are built from these engines. Quite a few are yes, but sometimes the technical baggage of the engine is so great - in that steers design directions - that it's chea
Re: (Score:2)
Given how many complaints I've heard about the Unreal engine in general, I'd have to imagine that with the apparent headaches of getting licensed games to run right just on Windows and t
Re: (Score:2)
2. Development setup
3. QA
4. Support
5. Platform-specific APIs added to, say, make shortcuts or turn off screensavers or whatnot
Part of this can be solved by rogue developers, but not all. And believe me, once a developer is accustomed to the system, he'll realize his effort is in vain because no management would let him release untested and unsupported code, nor would management want to test or support something with so little ROI (return on investment). You could invest that money and tim
Re:You won't get good games until you get marketsh (Score:2)
Re: (Score:2)
From what I've heard, Loki didn't die due to a lack of customers. They died because of personnel problems, and because their profit margin wasn't good enough to make up for their other shortcomings.
Re:You won't get good games until you get marketsh (Score:2)
http://irrlicht.sourceforge.net/tut012.html [sourceforge.net]
If you don't like Irrlicht, y
No, it isn't (Score:2)
Should it matter? (Score:3, Insightful)
Perhaps people just don't want to run their games as root though....
Re: (Score:2)
Absolutely not, you want your games to have a high priority but not that high of a priority. Real time tasks have a high potential for locking up the system, if there's a bad loop in a normal priority application then you can stop it - if there's one in a r
Re: (Score:2)
Modular Kernel (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Pluggable (Score:5, Insightful)
You didnt read TFA (Score:2)
Re: (Score:2)
Beat out at *framerate*, which isn't the same thing as responsiveness, although those two things are generally positively correlated.
The numbers that would really help in this argument are things like "standard deviation of inter-frame delay". If you can come up with a good way of measuring that, that'd be great.
Re:Pluggable (Score:5, Informative)
Re: (Score:2)
Multiple choice schedulers (Score:2, Informative)
Scheduler Nanokernel (Score:3, Interesting)
Actually, I'd like to see the OS kernel consist entirely of only the scheduler and the thinnest APIs to secure drivers granting access to the HW. Everything else, including IPC, could be in userspace.
That would make distributing the OS a lot easier. And the simplicity could be a lot easier to secure, to develop for, to customize a deployment for minimum HW (like eg. a "self-winding" 10mW Bluetooth ring with "accessory" features). Practically every device could run the same "OS", with modules bolted on for increased functionality on heavier HW.
What you describe is called... (Score:2)
Re: (Score:2)
I see there's a Minix 3.0. Is there any possibility of stripping Linux 2.6.x into processes that could call the Minix 3.0 kernel? Is anyone working on that way of making "Linux apps run on Minix"?
Re: (Score:2)
You can more or less engineer the kernel concept out of existence until it's nothing but an interrupt handler and a call gate. However, since the reality of commodity CPUs is that they're designed with hardware contexts and even C stacks (or perhaps I shoul
Re: (Score:2)
Eh-heh... I suppose since the subject of the post contained the word "nanokernel", that that was kind of redundant.
Re: (Score:2)
If customizing Linux to the specs I mentioned were so easy as downloading source and compiling (you skipped the hard part, factoring and looping back the extra codepaths), then all the distros that try it (probably starting with the "Linux on a
Setbacks? (Score:5, Insightful)
Linux and Games (Score:5, Insightful)
1. Set up your Linux system. Use onboard video and don't overspend on your processor.
2. Buy a PS2, a Wii, or a 360.
3. Play games on your game console and do everything else on Linux.
Be glad they chose CFS over SD then. (Score:5, Insightful)
From TFA [kerneltrap.org]
Vague generalizations on OS suitability (Score:2)
OS X is for artists and people really into style.
Linux is for hackers and various niche environments.
Linux does not need to support gaming. Windows does that quite well. Anyone that wants to game can dual-boot with Windows, or buy a console. Linux will not support gaming, for the same reasons AIX or Solaris are not chock full of gaming goodness. It isn't required or desired, and the OS is far more suitable for other, often more "serious," applications.
Re: (Score:2)
While I agree that what I am about to describe can very much be considered a "niche environment", pretty much every single kernel developer develops Linux for his own desktop. Linus created Linux in the beginning so that he could have a full Unix-like OS on a 386.
So Linux' entire existence is for the desktop. It has proven to be a very great server OS as well. And a lot of people develop it for that purpose. But Linus himself, when responding to Con's clai
Re: (Score:2)
The past is the map to the future (Score:2)
Other than Security, to the average user who is using Windows there just is'nt the "Whoahh" that people used to get when somebody back then saw the Amiga or Atari. Compelling reasons just don't exist for the average user to switch from windows to LINUX except maybe fear of viruses and malware.
For games to take off on L
The X Factor (Score:5, Interesting)
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: (Score:3, Interesting)
Well the GP was talking about pressing a key, so that's definitedly user input..
And the latency for the reaction to user input is quite critical for a game, but does the kernel --> X server --> games context switches induce really a measurable latency for a player?
I don't know..
The Scheduler That Lived will live (Score:2)
There were a lot of testers when SD came out, because it clearly beat the pants off the old one, and that was exactly why Ingo went ahead to throw his own version of a fair scheduler - otherwise his code would not survive.
Which one is better, SD or CFS? Technically, it was hard to say, but it's not about technology - it's like the browser war, the one with the bigger market share
Jitter is important (Score:5, Interesting)
I have seen several projects, where user interface response time problems have been "improved" by making adding a minimum response time. The average response time increases, but variation decreases, and the user often reports the program as having become faster... the logic to this seems to be, that the user wants the user interface to have a predictable response.
I think the reference for this is Søren Lauesens books about usability programming, but I cannot remember for sure right now.
CFS's impact is.. none! (Score:3, Funny)
And then the news post here, says "Linux cannot suffer any setbacks in gaming". I think you'll find that compared to the original scheduler, CFS pretty much rocks for gaming. As much or less than SD, who the fuck cares?
It's better than the original scheduler, so where's the setback?
If it's not as good as SD, oh well, cry me a river. I don't agree with Linus' "there is no maintainer" idea, but more the concept that CFS removes more lines from the kernel than it replaces, and does a better job, whereas SD adds complexity for roughly the same effect. What could be a perfectly good technical reason in previous LKML posts got turned into politiking.
Difference between SD and CFS.. fractions of a frame per second. WOW. That really means Linus made the wrong decision! The impact on games, where 1/500th of a second really MAKES A DIFFERENCE is too high! Put the old scheduler back you fucking crazy-ass Finn!!
Re:Hmm (Score:4, Funny)
Re: (Score:2)
Strange, I've been gaming in Linux for years. (Score:5, Interesting)
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.
Re: (Score:2)
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.
Doom 3 is a native Linux game, as are most, if not all, id Software games.
I get a few FPS more in RTCW: Enemy Territory in Linux (natively), though I generally have fewer background apps/services running than in Windows. But that's just an old game that I still like to play. I'll have to see how the much higher spec'd ET: Quake Wars handles when it comes out.
Re: (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: (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:4, Insightful)
On the other hand, performance drawbacks because of wine's virtualization are very small but naturally they do exist. Adding an extra layer of wrapping takes time. Of course, maybe wine's handling of win32-specific calls and systems is more efficient than Microsoft's implementation in their operating systems
Re:Strange, I've been gaming in Linux for years. (Score:4, Interesting)
An efficient scheduler gives processes in general the most bandwidth. A fair scheduler gives processes in a priority class the most equal bandwidth shares. A real time scheduler gives any given process the most predictable wait for bandwidth.
Each of these notions is somewhat different. Achieving a high frame rate over the course of a test on an unloaded system tells you nothing about the scheduler, other than perhaps it is not truly awful. On a moderately loaded system, the scheduler may be giving your game more than its share of CPU time, but if from time to time your game seizes up for a fraction of a second, it would be an irritation, even if on average it's getting enough bandwidth to give you a good playing experience. At the same time, this situation would be fine for data processing applications like image analysis, where an operation might take several seconds, or even minutes to complete. As long as the process gets plenty of cycles over the course of the operation, it's ok, even though your operation might have "frozen" for up to a second in the process.
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:Strange, I've been gaming in Linux for years. (Score:5, Informative)
Games and VS (Score:2)
Re:Games.. only thing keeping me from linux full-t (Score:2, Insightful)
Then I realized it doesn't matter which operating system I run as long as I can do what I need to do. I was only trying to switch to Linux for ideological reasons, not for any practical reason. The act of switching over was going to involve a lot of time, ef