I have managed to stay away from video games for the past few months but decided to pick up one of my old favorites and spend a little time playing. Much to my dismay, 3D performance had regressed since the last time I played a full-on video game. Most FOSS and commercial games were running at 10 FPS or so. 32 and 64 bit. 100% CPU utilization.
Well, after running some oprofile and sysprof stuff, I discovered that some 60% of the CPU was being spent on in-Xorg and in-Kernel video computation. So, I thought surely it was related to some new DRI2 stuff I was running. So... I went backwards two years in Intel graphics driver development. No change; little faster. I went forward to the very latest and greatest stuff (and X, kernel and userspace Mesa): Gallium3D with DRI2 state tracker on KMS. 30% speed up but still ~15 FPS on average. So it wasn't the driver...
Finally, I decided to pull out the big guns and SSH in to my laptop while playing to watch various things. During this, I discovered that CPUFreq ondemand never raised my frequency above 800MHz. "What?" I thought, "Surely ondemand is still reliable... isn't it?" We've been recommending to people that they always use ondemand since at least the 2.6.9 days. So, after:
sudo cpufreq-set -c 0 -g performance sudo cpufreq-set -c 1 -g performance
And running every game I have, beautifully, at generally around 60 FPS (vsync), I was armed with new information to Google. And indeed, there are reports starting around mid-last year that ondemand was having major regressions. And they appear to have been largely ignored, so far.
So, does anyone know what the hell is going on with ondemand?
Here's some anecdotal evidence which may help: computational benchmarks which do 100% of their calculation in user-space correctly scale the CPU; anything which performs a portion of its work inside the kernel (graphics related stuff) does not scale the CPU
For now, my laptop has roughly 50% battery life. *sigh*
Update 2009-04-12: I had been building my own kernel throughout the mentioned series and then switched to the official Debian 2.6.29 series--the problem was still there. A week ago, I switched to Fedora--to get closer to Gnome development in more aspects--and discovered that Fedora's build of 2.6.29 is not affected. I haven't had a chance to look it what the underlying differences might be but perhaps some enterprising person will beat me to it.

Comments
Good thing there's a cpu frequency applet for the occasion :)
Obviously though games will use any CPU time that's available, so without throttling you'll be left with more speed and more energy usage.
Be sure to test the actual battery life with both settings though.
It is very likely that ondemand does switch up and back again.
When playing a game here It is around 60% in highest speed and rest in lowest.
To change the value, use this command (for example for 50%).
echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ond
Dumb question, maybe you have thought of this. If the laptop is a dual core and the game is single threaded, then shouldn't the threshhold be set at 40% instead of 80%? You want full speed as soon as a single core is pegged.
I know that in the past, this was an obvious problem and fix.
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ond
With my Fedora 10 laptop I've installed newer driver stuff from rawhide to get it up to DRI2 status and get stable Intel performance.
I noticed that I get a 30-50% boost in performance if I disable ondemand.
To examples that I can think of off the top of my head is:
Maniadrive, car racing game. Disabling ondemand took the fps from the 30-60 range to the 70-90 range.
for playing large Adobe Flash videos, like the stuff you can get from Hulu.com, (which unfortunately won't work with gnash or anything else yet) I have OpenGL forced on. You can do this with:
OverrideGPUValidation=true
in:
/etc/adobe/mms.cfg
This gets you good flash performance under Intel UXA stuff in DRI2-land. Even works well with Compiz.
While with ondemand I may get choppy video playback on moderately busy parts of movies. With it disabled I get much smoother results.
---------------------
And ya this sort of thing can cause stuttering in Pulse-audio. Any time your going to have a video go out of sync due to bad video performance or anything like that it is going to cause cascading problems.
However: A performance tip for pulseaudio is to:
A. give yourself the ability to run with realtime priorities (edit /etc/security/limits.conf, add yourself to pulse-rt or whatever else is appropriate for your system.)
This will solve a lot of stuttering issues, but will not help if PA is consuming lots of CPU time.
So...
B: Change the mixer resampler method. In /etc/pulse/daemon.conf you can find something like:
; resample-method = speex-float-3
This is moderately high quality sampling method, but unless your using something like a nice Core Duo cpu or better it is going to eat a irritatingly large amount of CPU time.
I find that with
resample-method = ffmpeg
I get good results on my 1.6ghz Atom-based Netbook, which has about the cpu performance of a 600mhz-1ghz Pentium3.
With resample-method = trivial you can get about the same level of overhead that you get from simply using dmix.
(I think. I can't find anywere that documents the method used by dmix)
So people with older machines should look into that. It is then quite a bit better then simply pages and pages of Ubuntu forums telling people to shut off pulse audio because it is shit.
And the same thing with DRI2 and ondemand...
I think I should just set it up so that it runs with the 'performance' governor unless my screensaver is active..
But I digress.. my problem != your problem
When on power, the scaling misbehaves dramatically, and cpufreq-info has actually told me it can only go from 800mhz to 800mhz. The cpufreq* scripts have, for some reason, lost their suid bit, which means the applet can't use them to set anything, and from the behaviour after I restored them, it looks like the system itself doesn't do scaling properly without it. The ondemand governor, that should jump from 800 to 2.0, is scaling like the conservative governor instead for some reason. Having anything except the performance governor = always at 800 for most things (including FF, any IDEs, compiling, ...). I personally know people who bought laptops and have them completely crippled 99% of the time with no idea how to fix it... it's not only the ondemand governor that's broken, there's real problems going on here with all the scaling pieces. :(
Additionally, subsequent to my posting of this, I have gotten a number of "me too's" from very smart people whom have had no luck tracking this down. So, I'm not optimistic.
Thank you. Nice constructive discussion and good find, hope it gets solved!
Just let me second that. There is at least an Ubuntu bug that sounds like the same issue (although only user space applications are involved). Would be nice to get things together:
https://bugs.launchpad.net/ubuntu/+sourc
I've always played with the scheduler set to ondemand, and can't complain about any perf issues (played quake wars on highest settings, currently on savage2 with medium-high). 8600m gt here.
I'll try 'performance' tonight though.
8600m gt, ubuntu 8.10, nvidia drivers.
May I ask which distro you use?
I am especially curious because of this paragraph: "I went forward to the very latest and greatest stuff (and X, kernel and userspace Mesa): Gallium3D with DRI2 state tracker on KMS." ... this sounds like pretty fun stuff to try. Vanilla Ubuntu isn't exactly shoving bleeding edge stuff like this in your face, so ... what are you using?
Thanks!
I'm really disturbed to think of how many 9.04 users might be running with a 50% clock speed and never know it.
Log messages are generated (in kern.log or similar log files) when one attempts to switch from performance governor to ondemand governor, to the effect of:
"ondemand governor failed, too long transition latency of HW, fallback to performance governor"
which may indicate that this "feature" may be "active". I have not verified whether or not the source change(s) are the same as those involved in some other comments.
The kernel comments suggest that this was done due to long latencies in speeding up or slowing down the CPU which I find to not be the case with my Pentium IV Prescott (P4D). CPU scales down or up relatively easily (within a few seconds or less) based on load. This has a real impact on power use (the machine (a significantly upgraded HP Pavilion a630n) drops from ~147W @ 2.8 GHz to ~107W @ 350 MHz = ~25% savings). I think there may be a push by kernel developers to encourage people to move to using the more complex cpufreqd approach to power conservation which may be a bit of overkill for typical desktop (AC-always-on) systems.
It is also worth noting that the Linux configuration "help" regarding X86_P4_CLOCKMOD is a bit misleading. I do not find that the "slowdowns"/"latencies" it allows are "excessive" (indeed they seem fine for normal desktop use). It also seems that having P4_CLOCKMOD in the kernel may be required for other power utilities (Gnome Frequency Scaling Monitor for example) to function because it seems to be required to enable the creation of the "/sys/devices/system/cpu/cpu0/cpufreq/*"
Robert Bradbury (robert.bradbury@gmail.com)