From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Viresh Kumar <viresh.kumar@linaro.org>,
"Joel Fernandes (Google.)" <joelaf@google.com>
Cc: linux-kernel@vger.kernel.org,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Juri Lelli <juri.lelli@redhat.com>,
Luca Abeni <luca.abeni@santannapisa.it>,
Todd Kjos <tkjos@google.com>,
claudio@evidence.eu.com, kernel-team@android.com,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked
Date: Tue, 22 May 2018 13:31:45 +0200 [thread overview]
Message-ID: <6163159.YL3rkaEOau@aspire.rjw.lan> (raw)
In-Reply-To: <20180522105429.yn2omuz63oa2w3ez@vireshk-i7>
On Tuesday, May 22, 2018 12:54:29 PM CEST Viresh Kumar wrote:
> On 22-05-18, 12:50, Rafael J. Wysocki wrote:
> > Ugly indeed.
>
> Hehe. I was thinking, maybe we can write wrapper helpers around lock/unlock
> which are stored as pointers in sg_policy. So that those are only set to
> non-NULL values (or non-Noop routines) for slow-switching single policy or
> any-switching shared policy systems. Then we can get rid of such conditional
> locking attempts :)
>
>
So below is my (compiled-only) version of the $subject patch, obviously based
on the Joel's work.
Roughly, what it does is to move the fast_switch_enabled path entirely to
sugov_update_single() and take the spinlock around sugov_update_commit()
in the one-CPU case too.
---
kernel/sched/cpufreq_schedutil.c | 57 ++++++++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 19 deletions(-)
Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===================================================================
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -92,9 +92,6 @@ static bool sugov_should_update_freq(str
!cpufreq_can_do_remote_dvfs(sg_policy->policy))
return false;
- if (sg_policy->work_in_progress)
- return false;
-
if (unlikely(sg_policy->need_freq_update))
return true;
@@ -103,25 +100,25 @@ static bool sugov_should_update_freq(str
return delta_ns >= sg_policy->freq_update_delay_ns;
}
-static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
- unsigned int next_freq)
+static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time,
+ unsigned int next_freq)
{
- struct cpufreq_policy *policy = sg_policy->policy;
-
if (sg_policy->next_freq == next_freq)
- return;
+ return false;
sg_policy->next_freq = next_freq;
sg_policy->last_freq_update_time = time;
- if (policy->fast_switch_enabled) {
- next_freq = cpufreq_driver_fast_switch(policy, next_freq);
- if (!next_freq)
- return;
+ return true;
+}
- policy->cur = next_freq;
- trace_cpu_frequency(next_freq, smp_processor_id());
- } else {
+static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
+ unsigned int next_freq)
+{
+ if (!sugov_update_next_freq(sg_policy, time, next_freq))
+ return;
+
+ if (!sg_policy->work_in_progress) {
sg_policy->work_in_progress = true;
irq_work_queue(&sg_policy->irq_work);
}
@@ -277,6 +274,7 @@ static void sugov_update_single(struct u
{
struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util);
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
+ struct cpufreq_policy *policy = sg_policy->policy;
unsigned long util, max;
unsigned int next_f;
bool busy;
@@ -307,7 +305,23 @@ static void sugov_update_single(struct u
sg_policy->cached_raw_freq = 0;
}
- sugov_update_commit(sg_policy, time, next_f);
+ if (policy->fast_switch_enabled) {
+ if (!sugov_update_next_freq(sg_policy, time, next_f))
+ return;
+
+ next_f = cpufreq_driver_fast_switch(policy, next_f);
+ if (!next_f)
+ return;
+
+ policy->cur = next_f;
+ trace_cpu_frequency(next_f, smp_processor_id());
+ } else {
+ raw_spin_lock(&sg_policy->update_lock);
+
+ sugov_update_commit(sg_policy, time, next_f);
+
+ raw_spin_unlock(&sg_policy->update_lock);
+ }
}
static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
@@ -376,13 +390,18 @@ sugov_update_shared(struct update_util_d
static void sugov_work(struct kthread_work *work)
{
struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work);
+ unsigned int next_freq;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&sg_policy->update_lock, flags);
+ next_freq = sg_policy->next_freq;
+ sg_policy->work_in_progress = false;
+ raw_spin_unlock_irqrestore(&sg_policy->update_lock, flags);
mutex_lock(&sg_policy->work_lock);
- __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
+ __cpufreq_driver_target(sg_policy->policy, next_freq,
CPUFREQ_RELATION_L);
mutex_unlock(&sg_policy->work_lock);
-
- sg_policy->work_in_progress = false;
}
static void sugov_irq_work(struct irq_work *irq_work)
next prev parent reply other threads:[~2018-05-22 11:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 18:55 Joel Fernandes (Google.)
2018-05-18 21:13 ` Saravana Kannan
2018-05-18 21:17 ` Rafael J. Wysocki
2018-05-21 5:14 ` Viresh Kumar
2018-05-21 8:29 ` Rafael J. Wysocki
2018-05-21 9:57 ` Juri Lelli
2018-05-21 16:13 ` Joel Fernandes
2018-05-22 10:02 ` Rafael J. Wysocki
2018-05-22 11:26 ` Rafael J. Wysocki
2018-05-22 15:30 ` Rafael J. Wysocki
2018-05-22 17:07 ` Rafael J. Wysocki
2018-05-21 10:50 ` Patrick Bellasi
2018-05-21 15:49 ` Joel Fernandes
2018-05-21 17:00 ` Patrick Bellasi
2018-05-21 17:20 ` Joel Fernandes
2018-05-21 17:41 ` Patrick Bellasi
2018-05-22 10:23 ` Viresh Kumar
2018-05-22 10:38 ` Patrick Bellasi
2018-05-21 18:05 ` Joel Fernandes
2018-05-22 10:26 ` Patrick Bellasi
2018-05-22 10:34 ` Viresh Kumar
2018-05-22 10:50 ` Viresh Kumar
2018-05-22 10:50 ` Rafael J. Wysocki
2018-05-22 10:54 ` Viresh Kumar
2018-05-22 11:31 ` Rafael J. Wysocki [this message]
2018-05-22 11:38 ` Viresh Kumar
2018-05-22 11:42 ` Rafael J. Wysocki
2018-05-22 12:22 ` Rafael J. Wysocki
2018-05-22 15:27 ` Rafael J. Wysocki
2018-05-22 21:41 ` Joel Fernandes
2018-05-22 21:52 ` Rafael J. Wysocki
2018-05-22 22:28 ` Joel Fernandes
2018-05-22 10:51 ` Patrick Bellasi
2018-05-22 10:56 ` Viresh Kumar
2018-05-22 22:09 ` Joel Fernandes
2018-05-23 8:18 ` Rafael J. Wysocki
2018-05-23 9:01 ` Viresh Kumar
2018-05-23 9:42 ` Joel Fernandes
2018-05-23 10:06 ` 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=6163159.YL3rkaEOau@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=claudio@evidence.eu.com \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=tkjos@google.com \
--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
all inboxes | Powered by JetHome®