(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?