Race to idle and tuning ondemand

[Arjan van de Ven]

John McCabe-Dansted wrote:
> Are there any other issues you'd like to me pass on to Ubuntu? Either
> tweaks of existing settings (which might get past the Hardy feature
> freeze), or longer term features?
> 
> On Feb 17, 2008 4:15 PM, Arjan van de Ven <arjan at linux.intel.com> wrote:
>> no; for that you want to increase the sampling rate, that actually has makes the system go
>> to full speed faster. Changing up_threshold is just giving the algorithm more cushing for
>> sampling errors (btw the measurement errors are going away really soon, Venki is switching
>> ondemand over to an exact measurement rather than sampling, at which point up_threshold can go away too)
> 
> OK, in Ubuntu I get:
> 
> powersave_bias 0
> sampling_rate 80000
> sampling_rate_max 40000000
> sampling_rate_min 40000
> 
> Do these seem sane for an average desktop on AC power?
> 
> Also I've read that (counter-intuitively) setting sampling_rate to
> sampling_rate_max reduces the sampling rate, e.g.
>   http://www.lesswatts.org/projects/powertop/known.php
> Is this correct?
> 
>>> The only reference to up_threshold I found on this list was
>>>   http://www.mail-archive.com/power@bughost.org/msg00699.html
>>> which mentions using an up_threshold of about 75% when not in
>>> power-saving mode.
>>>
>>> So, there is little point in going much below 75%, even on AC power?
>> yep
> 
> Gnome power management seems to want to set these according to
> performance_ac and performance_battery.
> Setting these to 55 and 35 gives a up_threshold of 73% and 86%
> respectively (rather than 31% and 90%). Do you agree with this change?


this was a bug in g-p-m (well more a miscommunication between g-p-m, hal and what
these settings actually mean) which is fixed upstream to not do this anymore.
The gpm/hal people thought that tuning this setting would make ondemand respond
quicker to events. It doesn't. They know that now ;-)