Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1331790 > unrolled thread

Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with policy->rwsem held

Started by"Rafael J. Wysocki" <rafael@kernel.org>
First post2016-02-11 10:50 +0100
Last post2016-02-11 13:00 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with  policy->rwsem held "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-11 10:50 +0100
    Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with  policy->rwsem held Viresh Kumar <viresh.kumar@linaro.org> - 2016-02-11 13:00 +0100

#1331790 — Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with policy->rwsem held

From"Rafael J. Wysocki" <rafael@kernel.org>
Date2016-02-11 10:50 +0100
SubjectRe: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with policy->rwsem held
Message-ID<r0W2T-6Wl-15@gated-at.bofh.it>
On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> This isn't followed properly by all parts of the core code, some follow
> it, whereas others don't.

"The cpufreq core code is not consistent with respect to invoking
__cpufreq_governor() under policy->rwsem."

> Enforcing it will also enable us to remove cpufreq_governor_lock, that
> is used today because we can't guarantee that __cpufreq_governor() isn't
> executed in parallel.

"Changing all code to always hold policy->rwsem around
__cpufreq_governor() invocations will allow us to ..."

> We should also ensure that the lock is held across state changes to the
> governors.
>
> For example, while adding a CPU to the policy on cpu-online path, we
> need to stop the governor, change policy->cpus, start the governor and
> then refresh its limits. The complete sequence must be guaranteed to
> execute without any concurrent races. And that can be achieved using
> policy->rwsem around these use cases.
>
> Also note that cpufreq_driver->stop_cpu() and ->exit() can get called
> while policy->rwsem is held. That shouldn't have any side effects
> though.

The last paragraph is unclear.

Is it supposed to mean that the change will cause
cpufreq_driver->stop_cpu() and ->exit() to be called under
policy->rwsem sometimes?

Thanks,
Rafael

[toc] | [next] | [standalone]


#1331855

FromViresh Kumar <viresh.kumar@linaro.org>
Date2016-02-11 13:00 +0100
Message-ID<r0Y4H-8bX-21@gated-at.bofh.it>
In reply to#1331790
On 11-02-16, 10:48, Rafael J. Wysocki wrote:
> On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Also note that cpufreq_driver->stop_cpu() and ->exit() can get called
> > while policy->rwsem is held. That shouldn't have any side effects
> > though.
> 
> The last paragraph is unclear.
> 
> Is it supposed to mean that the change will cause
> cpufreq_driver->stop_cpu() and ->exit() to be called under
> policy->rwsem sometimes?

Yeah, reworded it a bit ..

Also note that, after this patch cpufreq_driver->stop_cpu() and ->exit()
will get called while policy->rwsem is held, which wasn't the case
earlier. That shouldn't have any side effects though.

-- 
viresh

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web