From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 03/10] cpufreq: conservative: remove 'enable' field
Date: Fri, 26 Jun 2015 11:27:49 +0530 [thread overview]
Message-ID: <558CE9DD.1050105@linux.vnet.ibm.com> (raw)
In-Reply-To: <e5627369b56ae3dcd00d7243e00618992c457cce.1434959517.git.viresh.kumar@linaro.org>
On 06/22/2015 01:32 PM, Viresh Kumar wrote:
> Conservative governor has its own 'enable' field to check two things:
> - If conservative governor is used for a CPU or not
> - If governor is currently enabled or not, as there can be a race around
> the notifier being called while it was getting unregistered from
> cpufreq_governor_dbs().
The race is between changing governors in cpufreq_set_policy() and the
notifier being called, isn't it ? The governor will get unregistered
when we remove the cpufreq module and here too we do not set
policy->governor to NULL nor set the enable bit to 0. So it does not
look like we were protecting these checks against un-registering the
governor.
>
> The first one can be checked by comparing policy->governor with
> 'cpufreq_gov_conservative' and the second one isn't that important. In
> the worst case, we will end up updating dbs_info->requested_freq. And
> that wouldn't do any harm.
>
Assuming the race that exists is indeed the one that I mentioned above,
it does not look like we will hit this case where we end up updating the
requested_freq unnecessarily.
stop conservative governor :
policy->governor is conservative.
STOP
gov_cancel_work() ----> The notifiers will not run after this point.
enable = 0
So while the notifiers are running, they will see that the
policy->governor is conservative and that enable = 1.
start conservative governor :
START
enable = 1
gov_start_work() ----> The notifiers will run after this point only.
So when they run, they will see that policy->governor = conservative and
enable = 1.
Both the fields are consistent with each other when notifiers run. It
thus looks like this patch will not bring about a difference in the
functionality, hence harmless.
Regards
Preeti U Murthy
> Lets get rid of this field.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq_conservative.c | 26 +++++++++++++++-----------
> drivers/cpufreq/cpufreq_governor.c | 12 +-----------
> drivers/cpufreq/cpufreq_governor.h | 1 -
> 3 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
> index 1e3cabfb2b57..f53719e5bed9 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -23,6 +23,19 @@
>
> static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
>
> +static int cs_cpufreq_governor_dbs(struct cpufreq_policy *policy,
> + unsigned int event);
> +
> +#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> +static
> +#endif
> +struct cpufreq_governor cpufreq_gov_conservative = {
> + .name = "conservative",
> + .governor = cs_cpufreq_governor_dbs,
> + .max_transition_latency = TRANSITION_LATENCY_LIMIT,
> + .owner = THIS_MODULE,
> +};
> +
> static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
> struct cpufreq_policy *policy)
> {
> @@ -124,7 +137,8 @@ static int dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
> if (!policy)
> return 0;
>
> - if (!dbs_info->enable)
> + /* policy isn't governed by conservative governor */
> + if (policy->governor != &cpufreq_gov_conservative)
> goto policy_put;
>
> /*
> @@ -371,16 +385,6 @@ static int cs_cpufreq_governor_dbs(struct cpufreq_policy *policy,
> return cpufreq_governor_dbs(policy, &cs_dbs_cdata, event);
> }
>
> -#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> -static
> -#endif
> -struct cpufreq_governor cpufreq_gov_conservative = {
> - .name = "conservative",
> - .governor = cs_cpufreq_governor_dbs,
> - .max_transition_latency = TRANSITION_LATENCY_LIMIT,
> - .owner = THIS_MODULE,
> -};
> -
> static int __init cpufreq_gov_dbs_init(void)
> {
> return cpufreq_register_governor(&cpufreq_gov_conservative);
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index af63402a94a9..836aefd03c1b 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -463,7 +463,6 @@ static int cpufreq_governor_start(struct cpufreq_policy *policy,
> cdata->get_cpu_dbs_info_s(cpu);
>
> cs_dbs_info->down_skip = 0;
> - cs_dbs_info->enable = 1;
> cs_dbs_info->requested_freq = policy->cur;
> } else {
> struct od_ops *od_ops = cdata->gov_ops;
> @@ -482,9 +481,7 @@ static int cpufreq_governor_start(struct cpufreq_policy *policy,
> static int cpufreq_governor_stop(struct cpufreq_policy *policy,
> struct dbs_data *dbs_data)
> {
> - struct common_dbs_data *cdata = dbs_data->cdata;
> - unsigned int cpu = policy->cpu;
> - struct cpu_dbs_info *cdbs = cdata->get_cpu_cdbs(cpu);
> + struct cpu_dbs_info *cdbs = dbs_data->cdata->get_cpu_cdbs(policy->cpu);
> struct cpu_common_dbs_info *ccdbs = cdbs->ccdbs;
>
> /* State should be equivalent to START */
> @@ -493,13 +490,6 @@ static int cpufreq_governor_stop(struct cpufreq_policy *policy,
>
> gov_cancel_work(dbs_data, policy);
>
> - if (cdata->governor == GOV_CONSERVATIVE) {
> - struct cs_cpu_dbs_info_s *cs_dbs_info =
> - cdata->get_cpu_dbs_info_s(cpu);
> -
> - cs_dbs_info->enable = 0;
> - }
> -
> ccdbs->policy = NULL;
> mutex_destroy(&ccdbs->timer_mutex);
> return 0;
> diff --git a/drivers/cpufreq/cpufreq_governor.h b/drivers/cpufreq/cpufreq_governor.h
> index 2125c299c602..a0d24149f18c 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -170,7 +170,6 @@ struct cs_cpu_dbs_info_s {
> struct cpu_dbs_info cdbs;
> unsigned int down_skip;
> unsigned int requested_freq;
> - unsigned int enable:1;
> };
>
> /* Per policy Governors sysfs tunables */
>
next prev parent reply other threads:[~2015-06-26 5:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 8:02 [PATCH 00/10] cpufreq: governor: Further cleanups (v4.3) Viresh Kumar
2015-06-22 8:02 ` [PATCH 01/10] cpufreq: Use __func__ to print function's name Viresh Kumar
2015-06-23 15:39 ` Preeti U Murthy
2015-06-22 8:02 ` [PATCH 02/10] cpufreq: conservative: Avoid races with transition notifier Viresh Kumar
2015-06-23 15:53 ` Preeti U Murthy
2015-06-24 1:11 ` Viresh Kumar
2015-06-25 7:59 ` Viresh Kumar
2015-06-22 8:02 ` [PATCH 03/10] cpufreq: conservative: remove 'enable' field Viresh Kumar
2015-06-26 5:57 ` Preeti U Murthy [this message]
2015-06-26 6:19 ` Viresh Kumar
2015-06-22 8:02 ` [PATCH 04/10] cpufreq: ondemand: only queue canceled works from update_sampling_rate() Viresh Kumar
2015-06-26 6:50 ` Preeti U Murthy
2015-06-26 7:28 ` Viresh Kumar
2015-06-22 8:02 ` [PATCH 05/10] cpufreq: governor: Drop __gov_queue_work() Viresh Kumar
2015-06-26 7:03 ` Preeti U Murthy
2015-06-26 7:32 ` Viresh Kumar
2015-06-22 8:02 ` [PATCH 06/10] cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate() Viresh Kumar
2015-06-26 7:20 ` Preeti U Murthy
2015-06-22 8:02 ` [PATCH 07/10] cpufreq: ondemand: queue work for policy->cpus together Viresh Kumar
2015-06-26 8:28 ` Preeti U Murthy
2015-06-26 8:52 ` Viresh Kumar
2015-06-22 8:02 ` [PATCH 08/10] cpufreq: ondemand: update sampling rate immidiately Viresh Kumar
2015-06-22 8:02 ` [PATCH 09/10] cpufreq: governor: Quit work-handlers early if governor is stopped Viresh Kumar
2015-06-22 8:02 ` [PATCH 10/10] cpufreq: Get rid of ->governor_enabled and its lock 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=558CE9DD.1050105@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).