RE: Increased ipw2200 power usage with dynticks

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Andi Kleen [mailto:andi@xxxxxxxxxxxxxx] 
>Sent: Tuesday, May 22, 2007 2:24 AM
>To: Pallipadi, Venkatesh
>Cc: Björn Steinbrink; Andi Kleen; Brown, Len; 
>tglx@xxxxxxxxxxxxx; mingo@xxxxxxx; Zhu, Yi; 
>linux-kernel@xxxxxxxxxxxxxxx; arjan@xxxxxxxxxxxxx; trenn@xxxxxxx
>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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/