Re: [PATCH] cpufreq: ondemand: Introduces stepped frequency increase

[Corrado Zoccolo]

Hi Venki,

On Wed, Jul 8, 2009 at 6:33 PM, Pallipadi,
Venkatesh<venkatesh.pallipadi@xxxxxxxxx> wrote:
> On Wed, 2009-07-08 at 09:10 -0700, Matthew Garrett wrote:
>> On Wed, Jul 08, 2009 at 03:56:33PM +0200, Corrado Zoccolo wrote:
>> > The patch introduces a new sysfs tunable cpufreq/ondemand/freq_step,
>> > as found in conservative governor, to chose the frequency increase step,
>> > expressed as percentage (default = 100 is previous behaviour).
>> >
>> > This allows fine tuning powersaving on mobile CPUs, since smaller steps will allow to:
>> > * absorb punctual load spikes
>> > * stabilize at the needed frequency, without passing for more power consuming states, and
>>
>> Is this a measured powersaving? The ondemand model is based on the
>> assumption that the idle state is disproportionately lower in power than
>> any running state, and therefore it's more sensible to run flat out for
>> short periods of time than run at half speed for longer. Is this
>> inherently flawed, or is it an artifact of differences in your processor
>> design?
>>
>
> As Matthew mentioned, ondemand governor wants to run at highest speed
> and get to idle sooner. Another aspect of ondemand governor is to have
> very low response time for freq increase on sudden increase in load.
> With freq_step, it may take long time before we can respond to sudden
> increase of load from idle to full busy.

Yes. freq_step is a tunable that allows trading latency for power saving.

>
> Even though you have default step as 100, as soon as we have this
> variable, there will be users/distros setting it in a wrong way.
>

I think having it as a tunable adds some value, since power managing
applications could use various inputs to chose the best value at run
time.
Some of them allow to specify complex policies, as switch to powersave
governor when battery charge is below a threshold.
With this change, one can gradually transition from current ondemand
to powersave, passing through intermediate states,
by feeding back the battery charge % into it, so the system is more
responsive when fully charged, and tries to save more power when it is
running low.

> So, it will be interesting to see any data you have with and without
> this change.

Ok, I'll collect some data.

>
> Alternatives to explore would be:
> - Can we identify some characteristics of this system and turn this on
> automatically instead of user tunable.
I think the user tunable has some reason to exist, to implement more
complex user policies as explained above.
We can identify, though, cases in which this should never be enabled,
like the P4s, in which the clock modulation reduces also the
memory-cache bandwidth. In those cases, the additional latency is very
noticeable, and can also be a loss in terms of power.

> - Long standing goal of combining conservative and ondemand with a
> mode_switch at the driver load, instead of run time tunables.
>
> Thanks,
> Venki
>
>



-- 
__________________________________________________________________________

dott. Corrado Zoccolo                          mailto:czoccolo@xxxxxxxxx
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
--
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/