From: Saravana Kannan <skannan@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done
Date: Wed, 26 Feb 2014 12:20:26 -0800 [thread overview]
Message-ID: <530E4C8A.6060906@codeaurora.org> (raw)
In-Reply-To: <CAKohpo==WVKytPCaMk=O5rGfPNFDAF7ffYo7OE0d3uAPyJfwwA@mail.gmail.com>
On 02/25/2014 10:02 PM, Viresh Kumar wrote:
> On 26 February 2014 07:18, Saravana Kannan <skannan@codeaurora.org> wrote:
>> On 02/25/2014 02:41 PM, Rafael J. Wysocki wrote:
>
>>> And is "fully initialized" actually well defined?
>>
>> The point in add dev/hot plug path after which we will no longer change
>> policy fields without sending further CPUFREQ_UPDATE_POLICY_CPU /
>> CPUFRE_NOTIFY notifiers.
>
> Okay..
>
>> Pretty much the end of __cpufreq_add_dev() so that it's after:
>> - cpufreq_init_policy()
>> - And the update of userpolicy fields that after thie init call
>
> No. In that case it can be considered initialized before cpufreq_init_policy().
> As we do send CPUFREQ_NOTIFY after that from cpufreq_init_policy()->
> cpufreq_set_policy().
Ok, valid hole in my definition of "fully initialized".
>
> There are two types of fields within policy, some are very basic: cpu/min/max/
> affected_cpus/related_cpus
>
> some are advanced: sysfs/governors/..
>
> And as a rule you have to get policy->rwsem lock before accessing policy
> members. We might not have followed it very well for small things like cpu.
>
> And so if you are doing anything over that, please use a lock and that is
> already present in cpufreq_update_policy().
>
> With my latest patchset that I sent yesterday, locking is improved and now
> a policy will be usable only after the rwsem is released. And that should be
> fine. And so making it available in the per-cpu variable after all the necessary
> fields are filled looks fine to me. And so I don't think we need to move it
> after call to cpufreq_init_policy(maybe a better name to this function is
> required)..
I'll take a closer look. Internal tree cpufreq code is in 3.12, so
back-porting all the cpufreq changes and testing it can take a bit of
time. Will get back on this.
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done
Date: Wed, 26 Feb 2014 12:20:26 -0800 [thread overview]
Message-ID: <530E4C8A.6060906@codeaurora.org> (raw)
In-Reply-To: <CAKohpo==WVKytPCaMk=O5rGfPNFDAF7ffYo7OE0d3uAPyJfwwA@mail.gmail.com>
On 02/25/2014 10:02 PM, Viresh Kumar wrote:
> On 26 February 2014 07:18, Saravana Kannan <skannan@codeaurora.org> wrote:
>> On 02/25/2014 02:41 PM, Rafael J. Wysocki wrote:
>
>>> And is "fully initialized" actually well defined?
>>
>> The point in add dev/hot plug path after which we will no longer change
>> policy fields without sending further CPUFREQ_UPDATE_POLICY_CPU /
>> CPUFRE_NOTIFY notifiers.
>
> Okay..
>
>> Pretty much the end of __cpufreq_add_dev() so that it's after:
>> - cpufreq_init_policy()
>> - And the update of userpolicy fields that after thie init call
>
> No. In that case it can be considered initialized before cpufreq_init_policy().
> As we do send CPUFREQ_NOTIFY after that from cpufreq_init_policy()->
> cpufreq_set_policy().
Ok, valid hole in my definition of "fully initialized".
>
> There are two types of fields within policy, some are very basic: cpu/min/max/
> affected_cpus/related_cpus
>
> some are advanced: sysfs/governors/..
>
> And as a rule you have to get policy->rwsem lock before accessing policy
> members. We might not have followed it very well for small things like cpu.
>
> And so if you are doing anything over that, please use a lock and that is
> already present in cpufreq_update_policy().
>
> With my latest patchset that I sent yesterday, locking is improved and now
> a policy will be usable only after the rwsem is released. And that should be
> fine. And so making it available in the per-cpu variable after all the necessary
> fields are filled looks fine to me. And so I don't think we need to move it
> after call to cpufreq_init_policy(maybe a better name to this function is
> required)..
I'll take a closer look. Internal tree cpufreq code is in 3.12, so
back-porting all the cpufreq changes and testing it can take a bit of
time. Will get back on this.
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-02-26 20:20 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 6:57 [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done Saravana Kannan
2014-02-24 6:57 ` Saravana Kannan
2014-02-24 7:42 ` Srivatsa S. Bhat
2014-02-24 7:42 ` Srivatsa S. Bhat
2014-02-24 8:11 ` Viresh Kumar
2014-02-24 8:11 ` Viresh Kumar
2014-02-24 8:41 ` skannan
2014-02-24 8:41 ` skannan at codeaurora.org
2014-02-24 8:43 ` Viresh Kumar
2014-02-24 8:43 ` Viresh Kumar
2014-02-24 8:47 ` skannan
2014-02-24 8:47 ` skannan at codeaurora.org
2014-02-24 8:50 ` Viresh Kumar
2014-02-24 8:50 ` Viresh Kumar
2014-02-24 9:00 ` skannan
2014-02-24 9:00 ` skannan at codeaurora.org
2014-02-24 8:39 ` skannan
2014-02-24 8:39 ` skannan at codeaurora.org
2014-02-24 10:55 ` Viresh Kumar
2014-02-24 10:55 ` Viresh Kumar
2014-02-24 20:23 ` Saravana Kannan
2014-02-24 20:23 ` Saravana Kannan
2014-02-25 8:50 ` Viresh Kumar
2014-02-25 8:50 ` Viresh Kumar
2014-02-25 13:04 ` Rafael J. Wysocki
2014-02-25 13:04 ` Rafael J. Wysocki
2014-02-25 14:40 ` Viresh Kumar
2014-02-25 14:40 ` Viresh Kumar
2014-02-25 14:40 ` Viresh Kumar
2014-02-25 21:11 ` Saravana Kannan
2014-02-25 21:11 ` Saravana Kannan
2014-02-25 22:41 ` Rafael J. Wysocki
2014-02-25 22:41 ` Rafael J. Wysocki
2014-02-26 1:48 ` Saravana Kannan
2014-02-26 1:48 ` Saravana Kannan
2014-02-26 6:02 ` Viresh Kumar
2014-02-26 6:02 ` Viresh Kumar
2014-02-26 20:20 ` Saravana Kannan [this message]
2014-02-26 20:20 ` Saravana Kannan
2014-02-26 3:38 ` [PATCH 1/3] cpufreq: stats: Remove redundant cpufreq_cpu_get() call Saravana Kannan
2014-02-26 3:38 ` Saravana Kannan
2014-02-26 5:06 ` Viresh Kumar
2014-02-26 5:06 ` Viresh Kumar
2014-02-26 20:04 ` Saravana Kannan
2014-02-26 20:04 ` Saravana Kannan
2014-02-26 3:38 ` [PATCH 2/3] cpufreq: stats: Fix error handling in __cpufreq_stats_create_table() Saravana Kannan
2014-02-26 3:38 ` Saravana Kannan
2014-02-26 3:38 ` Saravana Kannan
2014-02-26 5:11 ` Viresh Kumar
2014-02-26 5:11 ` Viresh Kumar
2014-02-26 3:38 ` [PATCH 3/3] cpufreq: Set policy to non-NULL only after all hotplug online work is done Saravana Kannan
2014-02-26 3:38 ` Saravana Kannan
2014-02-26 6:14 ` Viresh Kumar
2014-02-26 6:14 ` Viresh Kumar
2014-02-26 5:20 ` [PATCH] " Viresh Kumar
2014-02-26 5:20 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530E4C8A.6060906@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.