From: Joel Fernandes <joelaf@google.com>
To: linux-kernel@vger.kernel.org
Cc: Joel Fernandes <joelaf@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Josef Bacik <jbacik@fb.com>, Juri Lelli <Juri.Lelli@arm.com>,
Brendan Jackman <brendan.jackman@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
Rik van Riel <riel@redhat.com>, Ingo Molnar <mingo@redhat.com>
Subject: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag
Date: Sat, 26 Aug 2017 18:02:25 -0700 [thread overview]
Message-ID: <20170827010226.19703-1-joelaf@google.com> (raw)
Binder (Android's IPC mechanism) which uses sync wake ups during synchronous
transactions to the scheduler to indicate that the waker is about to sleep
soon. The current wake up path can improved when the sync flag is passed
resulting in higher binder performance. In this patch we more strongly wake up
the wakee on the waker's CPU if sync is passed based on a few other conditions
such as wake_cap, cpus allowed. wake_wide is checked only after the sync flag
check so that it doesn't mess up sync. Binder throughput tests see good
improvement improvement when waking up wakee (calling thread) on the waker's
CPU (called thread) with this flag. Some tests results are below:
On an 8-core ARM64 system, following is data from running
hwbinderThroughputTest with variable number of workers and services (the
workers are clients calling into the service threads and sleeps till the
service replies to them).
2 workers calling into 4 services:
Without patch: iterations per sec: 62757
With patch: iterations per sec: 75236 (+19.88%)
4 workers calling into 2 services:
Without patch: iterations per sec: 82379
With patch: iterations per sec: 85829 (+4.18%)
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Juri Lelli <Juri.Lelli@arm.com>
Cc: Brendan Jackman <brendan.jackman@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
Rik, as we discussed on IRC I am hoping that the lkp bot will also do its own
tests with this patch. I'm not sure if anything special needs to be in the
subject line to trigger the tests, if that's the case let me know and thanks!
kernel/sched/fair.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index eca6a57527f9..808571bc8ebe 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6276,10 +6276,19 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
int want_affine = 0;
int sync = wake_flags & WF_SYNC;
- if (sd_flag & SD_BALANCE_WAKE) {
+ if (sd_flag & SD_BALANCE_WAKE)
record_wakee(p);
- want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu)
- && cpumask_test_cpu(cpu, &p->cpus_allowed);
+
+ if ((sd_flag & SD_BALANCE_WAKE) && !wake_cap(p, cpu, prev_cpu)
+ && cpumask_test_cpu(cpu, &p->cpus_allowed)) {
+ /*
+ * WF_SYNC indicates waker will goto sleep, incase waker is
+ * the only one running, select the waker's CPU to run wakee
+ */
+ if (sync && cpu_rq(cpu)->nr_running < 2)
+ return cpu;
+
+ want_affine = !wake_wide(p);
}
rcu_read_lock();
--
2.14.1.342.g6490525c54-goog
next reply other threads:[~2017-08-27 1:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-27 1:02 Joel Fernandes [this message]
2017-08-27 5:44 ` [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag Mike Galbraith
2017-08-27 6:08 ` Mike Galbraith
2017-08-27 6:39 ` Joel Fernandes
2017-08-27 7:16 ` Mike Galbraith
2017-08-27 18:07 ` Mike Galbraith
2017-08-28 5:27 ` Joel Fernandes
2017-08-28 6:10 ` Mike Galbraith
2017-08-28 6:47 ` Mike Galbraith
2017-08-28 16:20 ` Joel Fernandes
2017-08-28 17:17 ` Mike Galbraith
2017-08-27 6:19 ` Joel Fernandes
[not found] ` <CAJWu+ooAPiuS+C7Gos4+8G9+DAvQL8X7=63D8U=yVLJkywbF7Q@mail.gmail.com>
2017-08-27 6:57 ` Mike Galbraith
2017-09-10 13:40 ` [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression kernel test robot
2017-09-10 16:53 ` Joel Fernandes
2017-09-11 2:55 ` Mike Galbraith
2017-09-11 6:32 ` Joel Fernandes
2017-09-11 8:03 ` Mike Galbraith
2017-09-14 15:56 ` Rik van Riel
2017-09-15 4:06 ` Mike Galbraith
2017-09-17 6:42 ` Joel Fernandes
2017-09-17 16:47 ` Mike Galbraith
2017-09-17 21:41 ` Joel Fernandes
2017-09-18 5:30 ` Mike Galbraith
2017-09-24 23:46 ` Joel Fernandes
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=20170827010226.19703-1-joelaf@google.com \
--to=joelaf@google.com \
--cc=Juri.Lelli@arm.com \
--cc=brendan.jackman@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=jbacik@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/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