Messages in this thread Patch in this message | | | Date | Tue, 2 Aug 2005 01:15:13 -0700 | From | Tony Lindgren <> | Subject | Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered) |
| |
* Con Kolivas <kernel@kolivas.org> [050802 00:36]: > On Tue, 2 Aug 2005 05:17 pm, Tony Lindgren wrote: > > * Lee Revell <rlrevell@joe-job.com> [050801 23:24]: > > > On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote: > > > > On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote: > > > > > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote: > > > > > > As a crude data point of idle system running a full kde desktop > > > > > > environment on > > > > > > powersave with minimal backlight and just chatting on IRC I find > > > > > > it's just > > > > > > under 10% battery life difference. > > > > > > > > > > Have you tried the same test but without artsd, or with it configured > > > > > to release the sound device after some reasonable time, like 1-2s? > > > > > > > > I have it on release after 1 second already. > > > > > > Is there any difference in power use between this, and not running artsd > > > at all? > > > > Please have the pmstats from http://www.muru.com/linux/dyntick running > > in once console with pmstats 5, and then just kill programs to find out > > which ones use lots of timers. CPU monitors etc. > > > > You should get X running at about 25HZ, (which is the PIT limit usually) > > Higher ticks means means polling somewhere which totally kills any power > > savings. > > Ok I seem to be bottoming out at 130Hz. I can't seem to kill off anything > more. > > > > > There's still some places in kernel that also do polling as far as I > > remember: > > > > - AT keyboard if no keyboard connected > > - Netfilter code (Unverified) > > > > But this you can verify by booting to single user mode and then running > > pmstats 5, and if ticks is not below 25HZ, there's something in the kernel > > polling. > > I'm removing modules and they don't seem to do anything so I'm not sure what > else to try.
If you have 130HZ in single user mode, it's some kernel driver. You could printk the the next timer, then grep for that in System.map:
--- linux-2.6.orig/kernel/timer.c 2005-06-27 07:51:58.000000000 -0700 +++ linux-2.6/kernel/timer.c 2005-06-28 06:57:27.000000000 -0700 @@ -571,6 +571,7 @@ expires = nte->expires; } } + printk("next: %08x\n", nte->function); spin_unlock(&base->t_base.lock); return expires; } Of course the console will be useless with this patch :)
I really need to do the timertop utility at some point...
Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |