Re: [PATCH V3 12/13] cpufreq: ondemand: Traverse list of policy_dbs in update_sampling_rate()

[Rafael J. Wysocki]

On Mon, Feb 8, 2016 at 6:20 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> On 08-02-16, 14:32, Rafael J. Wysocki wrote:
>> The comment still applies.
>>
>> Moreover, please extend it to say that this must be called with
>> dbs_data->mutex held (or it looks racy otherwise).
>
> Modified it as:
>
> + *
> + * Simply updating dbs_tuners_int.sampling_rate might not be appropriate here.
> + * For example, if the original sampling_rate was 1 second and the requested new
> + * sampling rate is 10 ms because the user needs immediate reaction from
> + * ondemand governor, otherwise the governor may change the sampling rate too
> + * late; up to 1 second later.

The "otherwise" doesn't seem to be necessary here.

> + *
> + * Similar logic applies while increasing the sampling rate. And so we need to
> + * update it with immediate effect.

Actually, no, it doesn't apply.  If you increase the sampling rate,
the governor will never be late.  It may be early, but that's fine in
this case.

It just doesn't hurt to update immediately in this case too.

> + *
> + * This must be called with dbs_data->mutex held, otherwise traversing
> + * policy_dbs_list isn't safe.

Thanks,
Rafael