Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1331790 > unrolled thread
| Started by | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| First post | 2016-02-11 10:50 +0100 |
| Last post | 2016-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.
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
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-02-11 10:50 +0100 |
| Subject | Re: [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]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2016-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