linux-kernel - Re: [PATCH V3 12/13] cpufreq: ondemand: Traverse list of policy_dbs in update_sampling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g3w2TAvpLO98DB+pNLHnEuRHS0JFn-Mxm8dtkNtfMwDg@mail.gmail.com>
Date:	Mon, 8 Feb 2016 23:05:45 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	Rafael Wysocki <rjw@...ysocki.net>,
	Juri Lelli <juri.lelli@....com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Michael Turquette <mturquette@...libre.com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Morten Rasmussen <morten.rasmussen@....com>,
	dietmar.eggemann@....com,
	Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 12/13] cpufreq: ondemand: Traverse list of policy_dbs
 in update_sampling_rate()

On Mon, Feb 8, 2016 at 6:20 PM, Viresh Kumar <viresh.kumar@...aro.org> 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