linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 */
> 


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