lkml.org 
[lkml]   [2016]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with policy->rwsem held
    From
    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

    \
     
     \ /
      Last update: 2016-02-11 11:21    [W:2.579 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site