On Thu, Nov 08, 2007 at 10:02:12AM -0800, Andrew Morton wrote:
> > On Thu, 08 Nov 2007 12:19:44 -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.
> >
> > 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
> >
> > 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?
> >
>
> That's a great report, thanks. Over to you, Mark ;)
>
> btw, I also have a note here that these patches caused Rafael to see an
> smp_call_function() inside local_irq_save(). Did that get fixed?
Ah, I see the problem. I think I posted a fix to this. The problem is
that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
be PM_QOS_CPU_DMA_LATENCY.
I'm not sure what's in the current MM tree at this point so I can't say
its been fixed. Is there an easy way from me to see what's currently in
MM?
FWIW I think I fixed this when I fixed up Rafael's issue. Would you
like me to send out a re-fresh patch against 2.6.23-mm1?
--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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
