On Thu, Nov 08, 2007 at 12:19:44PM -0500, [EMAIL PROTECTED] wrote: > (Sorry for not reporting this sooner - I haven't been running off battery > much in the last 3 weeks, so I didn't notice it till now...) > > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel. > > As reported by 'powertop' on a basically idle machine: > > 2.6.23-mm1: > > Cn Avg residency P-states (frequencies) > C0 (cpu running) (100.0%) 2.00 Ghz 0.8% > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0% > C2 0.0ms ( 0.0%) 1333 Mhz 0.0% > C3 0.0ms ( 0.0%) 1000 Mhz 99.2% > > 2.6.23-rc8-mm2: > > Cn Avg residency P-states (frequencies) > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0% > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0% > C2 0.0ms ( 0.0%) 1333 Mhz 0.0% > C3 31.5ms (99.7%) 1000 Mhz 100.0% > > In addition, the ACPI power estimate reported about 25 watts for 23-mm1, > but only 21 watts for -rc8-mm2, a significant regression.
well, thats because you burn less watts if you get into C3. > > I bisected this down to this set of patches: > > pm-qos-infrastructure-and-interface.patch > pm-qos-infrastructure-and-interface-fix.patch > pm-qos-infrastructure-and-interface-vs-git-acpi.patch > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch > latencyc-use-qos-infrastructure.patch yipes! I'll look at it right away. It looks like an integration issue with CPU-IDLE patches (those control the C-state entry). I'll get it fixed up. > > The patch says: > > To register the default pm_qos target for the specific parameter, the > process must open one of /dev/[cpu_dma_latency, network_latency, > network_throughput] > > As long as the device node is held open that process has a registered > requirement on the parameter. The name of the requirement is > "process_<PID>" derived from the current->pid from within the open system > call. > > I shouldn't have to have a process open a /dev/file, write a number, and then > stay around forever so the file doesn't close in order to get the same > behavior > I was getting by default before. What needs to happen to get this to not > be a behavior regression/change? > you won't have such a process (at least I highly doubt you do) I need to fix this. Thanks for taking the time to bisect it and reporting it to me! --mgross - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
