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
next prev parent reply other threads:[~2015-12-04 6:11 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 4:07 [PATCH V2 0/6] cpufreq: governor: replace per-cpu delayed work with timers Viresh Kumar
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 ` 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 ` 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 ` 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 ` Viresh Kumar
2015-12-03 4:07 ` [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers Viresh Kumar
2015-12-03 4:07 ` 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-04 6:13 ` Viresh Kumar
2015-12-09 2:04 ` [PATCH V4 " Viresh Kumar
2015-12-09 2:04 ` 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
2015-12-03 4:07 ` 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 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.