Hi,
while playing around with powertop, I noticed that my power usage wasn't
what it used to be. In total idle mode, everything was fine, but as soon
as I loaded the ipw2200 module and bring up the device, power usage
rises to about 16.8W, while kernel up to 2.6.20 used only about 15.3W. A
day worth of bisecting later, I could put my finger on dynticks, tested
2.6.22-rc1 without dynticks and power usage was at least down to about
15.5-15.6W, not perfect, but a lot better.
It seems that ipw2200 wants to do something about its power usage, but
dynticks stops it from doing so, as holding down the "Fn" key, and
thereby generating about 60 additional wakeups per second, brings the
power usage down to about the same as in the non-dynticks case.
Powertop also revealed, that with dynticks, my CPU is spending 99% in C2
when the power usage is high, but about 50% in C3 when I hold down "Fn".
Let me know if you need further details.
Thanks,
Bj?rn
On 2007.05.18 17:46:29 +0200, Bj?rn Steinbrink wrote:
> Hi,
>
> while playing around with powertop, I noticed that my power usage wasn't
> what it used to be. In total idle mode, everything was fine, but as soon
> as I loaded the ipw2200 module and bring up the device, power usage
> rises to about 16.8W, while kernel up to 2.6.20 used only about 15.3W. A
> day worth of bisecting later, I could put my finger on dynticks, tested
> 2.6.22-rc1 without dynticks and power usage was at least down to about
> 15.5-15.6W, not perfect, but a lot better.
>
> It seems that ipw2200 wants to do something about its power usage, but
> dynticks stops it from doing so, as holding down the "Fn" key, and
> thereby generating about 60 additional wakeups per second, brings the
> power usage down to about the same as in the non-dynticks case.
>
> Powertop also revealed, that with dynticks, my CPU is spending 99% in C2
> when the power usage is high, but about 50% in C3 when I hold down "Fn".
>
> Let me know if you need further details.
Ok, it seems that ipw2200 is just a trigger for the problem here. AFAICT
the cause of the worse C state usage is that after ipw2200 has woken the
cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
idea...) as the prefered sleep state. Now without NO_HZ or when I hold
down a key, there are interrupts that wake up the CPU and when
acpi_processor_idle() is called again the promotion to C3/C4 happens.
But with NO_HZ, there are no such interrupts, most wakeups are caused by
ipw2200 and so the processor doesn't go any deeper than C2 most of the
time and thus wastes lots of power.
Bj?rn
Bj?rn Steinbrink <[email protected]> writes:
>
> Ok, it seems that ipw2200 is just a trigger for the problem here. AFAICT
> the cause of the worse C state usage is that after ipw2200 has woken the
> cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
> idea...) as the prefered sleep state. Now without NO_HZ or when I hold
> down a key, there are interrupts that wake up the CPU and when
> acpi_processor_idle() is called again the promotion to C3/C4 happens.
> But with NO_HZ, there are no such interrupts, most wakeups are caused by
> ipw2200 and so the processor doesn't go any deeper than C2 most of the
> time and thus wastes lots of power.
The cpuidle governour code Venki is working on is supposed to address this.
There have been also earlier prototype patches by Adam Belay and
Thomas Renninger.
-Andi
On 2007.05.20 20:55:35 +0200, Andi Kleen wrote:
> Bj?rn Steinbrink <[email protected]> writes:
> >
> > Ok, it seems that ipw2200 is just a trigger for the problem here. AFAICT
> > the cause of the worse C state usage is that after ipw2200 has woken the
> > cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
> > idea...) as the prefered sleep state. Now without NO_HZ or when I hold
> > down a key, there are interrupts that wake up the CPU and when
> > acpi_processor_idle() is called again the promotion to C3/C4 happens.
> > But with NO_HZ, there are no such interrupts, most wakeups are caused by
> > ipw2200 and so the processor doesn't go any deeper than C2 most of the
> > time and thus wastes lots of power.
>
> The cpuidle governour code Venki is working on is supposed to address this.
> There have been also earlier prototype patches by Adam Belay and
> Thomas Renninger.
Venki (at least I think it was him) also told me about cpuidle and the
menu governor on #powertop. Unfortunately, cpuidle seems to be gone from
acpi-test (or I'm simply still too stupid for git/gitweb). I manually
added the cpuidle and menu governor patches on top of my 2.6.22-rc1-hrt8
kernel, but that broke C-state duration accounting.
On the bright side of things is power usage though, which is down to an
incredible 13.9W in idle+ipw2200 :)
Thanks,
Bj?rn
>-----Original Message-----
>From: Bj?rn Steinbrink [mailto:[email protected]]
>Sent: Monday, May 21, 2007 12:50 AM
>To: Andi Kleen
>Cc: [email protected]; [email protected]; Zhu, Yi;
>[email protected]; [email protected]; Pallipadi,
>Venkatesh; [email protected]
>Subject: Re: Increased ipw2200 power usage with dynticks
>
>On 2007.05.20 20:55:35 +0200, Andi Kleen wrote:
>> Bj?rn Steinbrink <[email protected]> writes:
>> >
>> > Ok, it seems that ipw2200 is just a trigger for the
>problem here. AFAICT
>> > the cause of the worse C state usage is that after ipw2200
>has woken the
>> > cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
>> > idea...) as the prefered sleep state. Now without NO_HZ or
>when I hold
>> > down a key, there are interrupts that wake up the CPU and when
>> > acpi_processor_idle() is called again the promotion to
>C3/C4 happens.
>> > But with NO_HZ, there are no such interrupts, most wakeups
>are caused by
>> > ipw2200 and so the processor doesn't go any deeper than C2
>most of the
>> > time and thus wastes lots of power.
>>
>> The cpuidle governour code Venki is working on is supposed
>to address this.
>> There have been also earlier prototype patches by Adam Belay and
>> Thomas Renninger.
>
>Venki (at least I think it was him) also told me about cpuidle and the
>menu governor on #powertop. Unfortunately, cpuidle seems to be
>gone from
>acpi-test (or I'm simply still too stupid for git/gitweb). I manually
>added the cpuidle and menu governor patches on top of my
>2.6.22-rc1-hrt8
>kernel, but that broke C-state duration accounting.
>
>On the bright side of things is power usage though, which is down to an
>incredible 13.9W in idle+ipw2200 :)
>
Nice to hear that cpuidle-menu governor gets 13.9W :-).
Powertop will need some changes to go with cpuidle, but that should be simple.
We need some more testing for cpuidle before it gets into git.
Len: Looks like cpuidle got dropped out of mm again. Can you merge it back it please.
Thanks,
Venki
>
> Nice to hear that cpuidle-menu governor gets 13.9W :-).
> Powertop will need some changes to go with cpuidle, but that should be simple.
>
> We need some more testing for cpuidle before it gets into git.
> Len: Looks like cpuidle got dropped out of mm again. Can you merge it back it please.
It probably needs some good review. I'm still not completely convinced
its full generity is needed for example. e.g. how would different governours
look like? Wouldn't it make more sense to concentrate on a single
policy ?
-Andi
Bj?rn Steinbrink wrote:
> On 2007.05.20 20:55:35 +0200, Andi Kleen wrote:
>> Bj?rn Steinbrink <[email protected]> writes:
>>> Ok, it seems that ipw2200 is just a trigger for the problem here. AFAICT
>>> the cause of the worse C state usage is that after ipw2200 has woken the
>>> cpu, acpi_processor_idle() chooses C2 (due to dma? bm? I have no
>>> idea...) as the prefered sleep state. Now without NO_HZ or when I hold
>>> down a key, there are interrupts that wake up the CPU and when
>>> acpi_processor_idle() is called again the promotion to C3/C4 happens.
>>> But with NO_HZ, there are no such interrupts, most wakeups are caused by
>>> ipw2200 and so the processor doesn't go any deeper than C2 most of the
>>> time and thus wastes lots of power.
>> The cpuidle governour code Venki is working on is supposed to address this.
>> There have been also earlier prototype patches by Adam Belay and
>> Thomas Renninger.
>
> Venki (at least I think it was him) also told me about cpuidle and the
> menu governor on #powertop. Unfortunately, cpuidle seems to be gone from
> acpi-test (or I'm simply still too stupid for git/gitweb). I manually
> added the cpuidle and menu governor patches on top of my 2.6.22-rc1-hrt8
> kernel, but that broke C-state duration accounting.
>
> On the bright side of things is power usage though, which is down to an
> incredible 13.9W in idle+ipw2200 :)
>
Very encouraging, hopefully that can get into mainline soon, as power
usage is an issue with laptops. Until then, it sounds as if dynticks is
a negative power save for ipw2200 (and probably many other things).
Dare we hope that this will allow use of USB on laptops without draining
the battery?
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
>-----Original Message-----
>From: Andi Kleen [mailto:[email protected]]
>Sent: Tuesday, May 22, 2007 2:24 AM
>To: Pallipadi, Venkatesh
>Cc: Bj?rn Steinbrink; Andi Kleen; Brown, Len;
>[email protected]; [email protected]; Zhu, Yi;
>[email protected]; [email protected]; [email protected]
>Subject: Re: Increased ipw2200 power usage with dynticks
>
>>
>> Nice to hear that cpuidle-menu governor gets 13.9W :-).
>> Powertop will need some changes to go with cpuidle, but that
>should be simple.
>>
>> We need some more testing for cpuidle before it gets into git.
>> Len: Looks like cpuidle got dropped out of mm again. Can you
>merge it back it please.
>
>It probably needs some good review. I'm still not completely convinced
>its full generity is needed for example. e.g. how would
>different governours
>look like? Wouldn't it make more sense to concentrate on a single
>policy ?
Agreed. I don't think we really need to have multiple governors being changed at run time.
The current idea is that we will have multiple governors changeable at run time only for
DEBUG and DEVELOPMENT. On a standard end user system there will be one governor
(current optimal governor) that will be loaded. This gives
flexibality to experiments with governors and also easily have different governors for
different kind of platforms - in future if needed (handheld v/s laptop v/s server).
Also, there are no overheads at runtime due to the fact that we have underlying infrastructure
to have multiple governors (no locking overheads and such).
The above comment is where we want to go. But, this is not there in the code yet. We should
have that pretty soon though.
Yes. Comments are welcome (once it is back in acpi-test/mm) as always.
Thanks,
Venki
>
>-Andi
>
> The current idea is that we will have multiple governors changeable at run time only for
> DEBUG and DEVELOPMENT. On a standard end user system there will be one governor
> (current optimal governor) that will be loaded. This gives
> flexibality to experiments with governors and also easily have different governors for
> different kind of platforms - in future if needed (handheld v/s laptop v/s server).
> Also, there are no overheads at runtime due to the fact that we have underlying infrastructure
> to have multiple governors (no locking overheads and such).
For testing/debugging you could just use some ifdefs, right?
-Andi