[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1495504859-10960-1-git-send-email-byungchul.park@lge.com>
Date: Tue, 23 May 2017 11:00:55 +0900
From: Byungchul Park <byungchul.park@....com>
To: <peterz@...radead.org>, <mingo@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <juri.lelli@...il.com>,
<rostedt@...dmis.org>, <bristot@...hat.com>, <kernel-team@....com>
Subject: [PATCH v5 0/4] Make find_later_rq() choose a closer cpu in topology
When cpudl_find() returns any among free_cpus, the cpu might not be
closer than others, considering sched domain. For example:
this_cpu: 15
free_cpus: 0, 1,..., 14 (== later_mask)
best_cpu: 0
topology:
0 --+
+--+
1 --+ |
+-- ... --+
2 --+ | |
+--+ |
3 --+ |
... ...
12 --+ |
+--+ |
13 --+ | |
+-- ... -+
14 --+ |
+--+
15 --+
In this case, it would be best to select 14 since it's a free cpu and
closest to 15(this_cpu). However, currently the code select 0(best_cpu)
even though that's just any among free_cpus. Fix it.
Change from v4
-. remove a patch that might cause huge lock contention
(by spin lock(&cpudl.lock) in a hot path of scheduler)
Change from v3
-. rename closest_cpu to best_cpu so that it align with rt
-. protect referring cpudl.elements with cpudl.lock
-. change return value of cpudl_find() to bool
Change from v2
-. add support for SD_PREFER_SIBLING
Change from v1
-. clean up the patch
Byungchul Park (4):
sched/deadline: Make find_later_rq() choose a closer cpu in topology
sched/deadline: Change return value of cpudl_find()
sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()
kernel/sched/cpudeadline.c | 26 ++++++++++++-------------
kernel/sched/deadline.c | 48 +++++++++++++++++++++++++++++++---------------
kernel/sched/rt.c | 17 ++++++++++++++++
3 files changed, 63 insertions(+), 28 deletions(-)
--
1.9.1
Powered by blists - more mailing lists