![]() | |||||||||||||
Messages in this thread |
Ed Sweetman wrote: > Robert Hancock wrote: >> Ed Sweetman wrote: >>> System is idle now, previously it was doing something i couldn't >>> halt at the time. I'm looking at "Local timer interrupts" in the >>> "Loc:" section of /proc/interrupts. >>> Across 1 second while the system is pretty much idle, i still get >>> 300 interrupts. My HZ variable is set to 300 in the kernel config, >>> so this is expected but I was under the assumption that >>> dynticks/tickless being compiled in would cause that to be much lower. >>> >>> Am I reading the wrong section of /proc/interrupts to verify if >>> dynticks is working or not? Again, i see no difference in cpu temp >>> at all. >> >> Try running powertop ( http://www.lesswatts.org/projects/powertop/ ) >> and see what it reports. >> >> I don't think dynticks will generally save huge amounts of power on a >> typical desktop machine. The big gains come from being able to stay >> in deep sleep C-states (C2/C3) for longer periods of time, but most >> desktop machines only enable sleep states down to C1. >> > I tried running powertop, it complains about not having timer > statistics, I looked throughout the kernel config for a timer stat > option, but can't find one. > > I didn't have hpet compiled in, i'm not sure if this is required but a > lot of places seem to suggest hpet and high precision timer and > tickless be compiled together. I also disabled cpuidle and i'll > reboot and try that. > read too fast through the powertop error message. timer stat info is in kernel_debug option. Which i did not compile in this latest kernel again. Sorry. Though, with hpet and such, i still see no measurable difference or any sort of evidence that ticks are being skipped (comparing /proc/interrupts across sleep 1s;) > >>> >>> In case it helps, this is an athlon64 x2 with apic functioning and >>> both cores active in 64bit mode. dmesg is below. >>> not related : >>> Some additional notes: it87 is my lm_sensor, it doesn't work in >>> this kernel, yet it did in 2.6.22. Perhaps enabling high precision >>> timers changed something in acpi land. >>> >>> I enabled tcp dma offloading in this kernel, i get debugging output >>> related to it, error is at the last line. No corruption or >>> otherwise bad behavior. Transferring via cifs at 9.7MB/sec >>> "incoming" took about 15% of one cpu... I never bothered to check >>> if that is the norm but i suspect i'll be removing that feature as >>> it seems to not play nice with the kernel. >> > | ||||||||||||
| Last update: 2007-12-08 06:31 [from the cache] ©2003-2008 | |||||||||||||