From: Uladzislau Rezki <urezki@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Mike Galbraith <efault@gmx.de>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
Subject: [PATCH] sched: ignore task_h_load for CPU_NEWLY_IDLE
Date: Tue, 14 Feb 2017 16:38:05 +0100 [thread overview]
Message-ID: <1487086685-7585-1-git-send-email-urezki@gmail.com> (raw)
From: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
A load balancer calculates imbalance factor for particular sched
domain and tries to steal up the prescribed amount of weighted load.
However, a small imbalance factor would sometimes prevent us from
stealing any tasks at all. When a CPU is newly idle, it should
steal first task which meets the migration criteria.
There is a slight improvement when it comes to frame drops
(in my case drops per/two seconds). Basically a test case is
left finger swipe on the display (21 times, duration is 2
seconds + 1 second sleep between iterations):
0 Framedrops: 7 5
1 Framedrops: 5 3
2 Framedrops: 8 5
3 Framedrops: 4 5
4 Framedrops: 3 3
5 Framedrops: 6 4
6 Framedrops: 3 2
7 Framedrops: 3 4
8 Framedrops: 5 3
9 Framedrops: 3 3
10 Framedrops: 7 4
11 Framedrops: 3 4
12 Framedrops: 3 3
13 Framedrops: 3 3
14 Framedrops: 3 5
15 Framedrops: 7 3
16 Framedrops: 5 3
17 Framedrops: 3 2
18 Framedrops: 5 3
19 Framedrops: 4 3
20 Framedrops: 3 2
max is 8 vs 5; min is 3 vs 2.
As for applied load, it is not significant and is "light".
Signed-off-by: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
---
kernel/sched/fair.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6559d19..b56b0c5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6802,6 +6802,15 @@ static int detach_tasks(struct lb_env *env)
if (env->idle != CPU_NOT_IDLE && env->src_rq->nr_running <= 1)
break;
+ /*
+ * Another CPU can place tasks, since we do not hold dst_rq lock
+ * while doing balancing. If newly idle CPU already got something,
+ * give up to reduce latency for CONFIG_PREEMPT kernels.
+ */
+ if (IS_ENABLED(CONFIG_PREEMPT) && env->idle == CPU_NEWLY_IDLE &&
+ env->dst_rq->nr_running > 0)
+ break;
+
p = list_first_entry(tasks, struct task_struct, se.group_node);
env->loop++;
@@ -6824,7 +6833,8 @@ static int detach_tasks(struct lb_env *env)
if (sched_feat(LB_MIN) && load < 16 && !env->sd->nr_balance_failed)
goto next;
- if ((load / 2) > env->imbalance)
+ if ((!IS_ENABLED(CONFIG_PREEMPT) || env->idle != CPU_NEWLY_IDLE) &&
+ (load / 2) > env->imbalance)
goto next;
detach_task(p, env);
--
2.1.4
reply other threads:[~2017-02-14 15:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1487086685-7585-1-git-send-email-urezki@gmail.com \
--to=urezki@gmail.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=peterz@infradead.org \
--cc=uladzislau2.rezki@sonymobile.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
Powered by JetHome