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 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.