linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	ashwin.chaugule@linaro.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers
Date: Fri, 4 Dec 2015 11:41:01 +0530	[thread overview]
Message-ID: <20151204061101.GA3430@ubuntu> (raw)
In-Reply-To: <10439879.00aCyM9quW@vostro.rjw.lan>

On 04-12-15, 02:18, Rafael J. Wysocki wrote:
> > +	shared->skip_work--;
> 
> Is there any reason for incrementing and decrementing this instead of setting
> it to either 0 or 1 (or maybe either 'true' or 'false' for that matter)?
> 
> If my reading of the patch is correct, it can only be either 0 or 1 anyway, right?

No. It can be 0, 1 or 2.

If the timer handler is running on any CPU, we increment skip_work, so
its value is 1. If at the same time, we try to stop the governor, we
increment it again and its value is 2 now.

Once timer-handler finishes, it decrements it and its value become 1.
Which guarantees that no other timer handler starts executing at this
point of time and we can safely do gov_cancel_timers(). And once we
are sure that we don't have any work/timer left, we make it 0 (as we
aren't sure of the current value, which can be 0 (if the timer handler
wasn't running when we stopped the governor) or 1 (if the timer
handler was running while stopping the governor)).

Hope this clarifies it.

> > +static void dbs_timer_handler(unsigned long data)
> > +{
> > +	struct cpu_dbs_info *cdbs = (struct cpu_dbs_info *)data;
> > +	struct cpu_common_dbs_info *shared = cdbs->shared;
> > +	struct cpufreq_policy *policy;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&shared->timer_lock, flags);
> > +	policy = shared->policy;
> 
> Why do we need policy here?
> 
> > +
> > +	/*
> > +	 * Timer handler isn't allowed to queue work at the moment, because:
> > +	 * - Another timer handler has done that
> > +	 * - We are stopping the governor
> > +	 * - Or we are updating the sampling rate of ondemand governor
> > +	 */
> > +	if (shared->skip_work)
> > +		goto unlock;
> > +
> > +	shared->skip_work++;
> > +	queue_work(system_wq, &shared->work);
> >  
> >  unlock:
> 
> What about writing the above as
> 
> 	if (!shared->work_in_progress) {
> 		shared->work_in_progress = true;
> 		queue_work(system_wq, &shared->work);
> 	}
> 
> and then you won't need the unlock label.

Here is a diff for that:

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index a3f9bc9b98e9..c9e420bd0eec 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -265,11 +265,9 @@ static void dbs_timer_handler(unsigned long data)
 {
        struct cpu_dbs_info *cdbs = (struct cpu_dbs_info *)data;
        struct cpu_common_dbs_info *shared = cdbs->shared;
-       struct cpufreq_policy *policy;
        unsigned long flags;
 
        spin_lock_irqsave(&shared->timer_lock, flags);
-       policy = shared->policy;
 
        /*
         * Timer handler isn't allowed to queue work at the moment, because:
@@ -277,13 +275,11 @@ static void dbs_timer_handler(unsigned long data)
         * - We are stopping the governor
         * - Or we are updating the sampling rate of ondemand governor
         */
-       if (shared->skip_work)
-               goto unlock;
-
-       shared->skip_work++;
-       queue_work(system_wq, &shared->work);
+       if (!shared->skip_work) {
+               shared->skip_work++;
+               queue_work(system_wq, &shared->work);
+       }
 
-unlock:
        spin_unlock_irqrestore(&shared->timer_lock, flags);
 }

I will resend this patch now.

-- 
viresh

  reply	other threads:[~2015-12-04  6:11 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1449115453.git.viresh.kumar@linaro.org>
2015-12-03  4:07 ` [PATCH V2 1/6] cpufreq: ondemand: Update sampling rate only for concerned policies Viresh Kumar
2015-12-03  4:07 ` [PATCH V2 2/6] cpufreq: ondemand: Work is guaranteed to be pending Viresh Kumar
2015-12-03  4:07 ` [PATCH V2 3/6] cpufreq: governor: Pass policy as argument to ->gov_dbs_timer() Viresh Kumar
2015-12-03  4:07 ` [PATCH V2 4/6] cpufreq: governor: initialize/destroy timer_mutex with 'shared' Viresh Kumar
2015-12-03  4:07 ` [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers Viresh Kumar
2015-12-04  1:18   ` Rafael J. Wysocki
2015-12-04  6:11     ` Viresh Kumar [this message]
2015-12-05  2:14       ` Rafael J. Wysocki
2015-12-05  4:10         ` Viresh Kumar
2015-12-07  1:28           ` Rafael J. Wysocki
2015-12-07  7:50             ` Viresh Kumar
2015-12-07 22:43               ` Rafael J. Wysocki
2015-12-07 23:17                 ` Rafael J. Wysocki
2015-12-08  0:39                   ` [PATCH][experimantal] cpufreq: governor: Use an atomic variable for synchronization Rafael J. Wysocki
2015-12-08  6:59                     ` Viresh Kumar
2015-12-08 13:30                       ` Rafael J. Wysocki
2015-12-08 13:36                         ` Viresh Kumar
2015-12-08 14:19                           ` Rafael J. Wysocki
2015-12-08 13:55                             ` Viresh Kumar
2015-12-08 14:30                               ` Rafael J. Wysocki
2015-12-08 14:56                                 ` Viresh Kumar
2015-12-08 16:42                                   ` Rafael J. Wysocki
2015-12-08 16:34                                     ` Viresh Kumar
2015-12-08  6:46                   ` [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers Viresh Kumar
2015-12-08  6:56                 ` Viresh Kumar
2015-12-08 13:18                   ` Rafael J. Wysocki
2015-12-08 13:30                     ` Viresh Kumar
2015-12-08 14:04                       ` Rafael J. Wysocki
2015-12-04  6:13   ` [PATCH V3 " Viresh Kumar
2015-12-09  2:04     ` [PATCH V4 " Viresh Kumar
2015-12-09 22:06       ` Rafael J. Wysocki
2015-12-10  2:36         ` Viresh Kumar
2015-12-10 22:17           ` Rafael J. Wysocki
2015-12-11  1:42             ` Viresh Kumar
2015-12-03  4:07 ` [PATCH V2 6/6] cpufreq: ondemand: update update_sampling_rate() to make it more efficient 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=20151204061101.GA3430@ubuntu \
    --to=viresh.kumar@linaro.org \
    --cc=ashwin.chaugule@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    /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).