kernelslacker (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} kernelslacker) wrote,@ 2006-01-11 22:24:00 |
|
tick tock tick tock.
About a week ago, I dug out my power measuring gizmo, and did some experiments with the 'dynamic tick' patch that has been floating around for quite a while, which stops the kernel waking up at a regular interval to check if any timers have expired, instead idling until the next timer in the system that expires. I was quite surprised at the results. Without the patch, my Athlon XP laptop idled at around 21W. With dynticks, after settling down for about a minute, the idle routine auto-calibrates itself and starts putting off delays. Suddenly, the power meter started registering.. 20,21,19,20,19,20,18,21,19,20,22 changing about once a second. Given the overall average power use went down below its regular idle power use, the patch does seem like a win. (For reference, Windows XP doesn't do anything like this, and idles at 20W on the same hardware).
Another useful datapoint, is that the dynticks patch also does some monitoring of which timers are firing regularly, so you can see whats causing the spikes of power every now and again, and hopefully do something about them, so that it stays idle for longer periods of time, and hence at a lower power drain for longer. It looks something like this after just a few minutes of idle time..
A few questions raised by this.
The highest hit count, rh_timer_func comes from USB hcd.c It's timer handler has this comment..
I'm not at one with the USB spec, but root hub interrupt transfers sound somewhat important, at least if you have any USB devices attached. For the times when I travel, and am on battery from now on though, I think I'll make a point of unloading unused modules like USB.
The next oddball is i8042_timer_func. This one is particularly odd, as it's responsible for handling interrupts from the keyboard/mouse controller. It's odd, because I wasn't touching the touchpad at all, and I didn't type that much. Logging in remotely shows that this increases over time no matter what. It seems to be there to poll for insertion of new PS2 devices, so could probably have its frequency toned down a little, instead of running at HZ/20.
cursor_timer_handler is another funny one. As best as I can tell, it's responsible for making sure the cursor on the framebuffer blinks at HZ/5
I wonder if setterm -blink off will make that disappear.
I have no idea which python process is continually causing so many process_timeout hits, but something keeps waking up regularly.
Hmm, the only thing in ps output is 'python ./hpssd.py' Looks like hplip. I don't own a HP printer, so I could just remove this I guess.
I've no idea why gdmgreeter keeps getting scheduled when it isn't even the active tty.
Xorg seems to be hitting it_real_fn quite a lot, even when it's not being used.
Seems to be part of the hi-res timers. I know X calls gettimeofday a lot, but I wasn't aware of it making excessive calls to sys_getitimer and friends. Puzzling.
It's surprising how many questions can be raised from just a little debug data. Tons of problems there that need tackling.
The dynticks patch itself needs quite a lot of work before it'd be ready for merging upstream, but it's an interesting feature to look forward to one day. It's currently i386 only, doesn't work on SMP, or even UP w/APIC. Quite a fun hack to play with though if you're lugging a 32-bit laptop around and want to squeeze a bit more out of your battery.
About a week ago, I dug out my power measuring gizmo, and did some experiments with the 'dynamic tick' patch that has been floating around for quite a while, which stops the kernel waking up at a regular interval to check if any timers have expired, instead idling until the next timer in the system that expires. I was quite surprised at the results. Without the patch, my Athlon XP laptop idled at around 21W. With dynticks, after settling down for about a minute, the idle routine auto-calibrates itself and starts putting off delays. Suddenly, the power meter started registering.. 20,21,19,20,19,20,18,21,19,20,22 changing about once a second. Given the overall average power use went down below its regular idle power use, the patch does seem like a win. (For reference, Windows XP doesn't do anything like this, and idles at 20W on the same hardware).
Another useful datapoint, is that the dynticks patch also does some monitoring of which timers are firing regularly, so you can see whats causing the spikes of power every now and again, and hopefully do something about them, so that it stays idle for longer periods of time, and hence at a lower power drain for longer. It looks something like this after just a few minutes of idle time..
peer_check_expire 181 crond dst_run_gc 194 syslogd rt_check_expire 251 auditd process_timeout 334 hald it_real_fn 410 automount process_timeout 437 kjournald process_timeout 1260 it_real_fn 1564 rpc.idmapd commit_timeout 1574 wb_timer_fn 1615 init process_timeout 1652 sendmail process_timeout 1653 process_timeout 1833 neigh_periodic_timer 1931 process_timeout 2218 hald-addon-stor process_timeout 3492 cpuspeed delayed_work_timer_fn 4447 process_timeout 7620 watchdog/0 it_real_fn 7965 Xorg process_timeout 13269 gdmgreeter process_timeout 15607 python cursor_timer_handler 34096 i8042_timer_func 35437 rh_timer_func 52912 (timer handler function, hit count, process [where known])
A few questions raised by this.
The highest hit count, rh_timer_func comes from USB hcd.c It's timer handler has this comment..
/* The USB 2.0 spec says 256 ms. This is close enough and won't
* exceed that limit if HZ is 100. */
if (hcd->uses_new_polling ? hcd->poll_rh :
(length == 0 && hcd->status_urb != NULL))
mod_timer (&hcd->rh_timer, jiffies + msecs_to_jiffies(250));
I'm not at one with the USB spec, but root hub interrupt transfers sound somewhat important, at least if you have any USB devices attached. For the times when I travel, and am on battery from now on though, I think I'll make a point of unloading unused modules like USB.
The next oddball is i8042_timer_func. This one is particularly odd, as it's responsible for handling interrupts from the keyboard/mouse controller. It's odd, because I wasn't touching the touchpad at all, and I didn't type that much. Logging in remotely shows that this increases over time no matter what. It seems to be there to poll for insertion of new PS2 devices, so could probably have its frequency toned down a little, instead of running at HZ/20.
cursor_timer_handler is another funny one. As best as I can tell, it's responsible for making sure the cursor on the framebuffer blinks at HZ/5
I wonder if setterm -blink off will make that disappear.
I have no idea which python process is continually causing so many process_timeout hits, but something keeps waking up regularly.
Hmm, the only thing in ps output is 'python ./hpssd.py' Looks like hplip. I don't own a HP printer, so I could just remove this I guess.
I've no idea why gdmgreeter keeps getting scheduled when it isn't even the active tty.
Xorg seems to be hitting it_real_fn quite a lot, even when it's not being used.
Seems to be part of the hi-res timers. I know X calls gettimeofday a lot, but I wasn't aware of it making excessive calls to sys_getitimer and friends. Puzzling.
It's surprising how many questions can be raised from just a little debug data. Tons of problems there that need tackling.
The dynticks patch itself needs quite a lot of work before it'd be ready for merging upstream, but it's an interesting feature to look forward to one day. It's currently i386 only, doesn't work on SMP, or even UP w/APIC. Quite a fun hack to play with though if you're lugging a 32-bit laptop around and want to squeeze a bit more out of your battery.
