On Tue, 4 Nov 2014 19:13:04 +0800
"pang.xunlei" <pang.xunlei@xxxxxxxxxx> wrote:
When selecting the cpu for a waking DL task, if curr is a non-DLThis looks fine, and I'm wondering if we shouldn't just move this into
task which is bound only on this cpu, then we can give it a chance
to select a different cpu for this DL task to avoid curr starving.
Signed-off-by: pang.xunlei <pang.xunlei@xxxxxxxxxx>
---
kernel/sched/deadline.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 7b0b2d2..1f64d4a 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -954,6 +954,9 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags)
struct task_struct *curr;
struct rq *rq;
+ if (p->nr_cpus_allowed == 1)
+ goto out;
+
kernel/sched/core.c: select_task_rq(). Why bother calling the select_rq
code if the task is pinned?
This change will make fair.c, rt.c, and deadline.c all start with the
same logic. If this should be an optimization, just move it to core.c
and be done with it.
if (sd_flag != SD_BALANCE_WAKE && sd_flag != SD_BALANCE_FORK)This has the same issue as the rt.c change.
goto out;
@@ -970,11 +973,14 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags)
* can!) we prefer to send it somewhere else. On the
* other hand, if it has a shorter deadline, we
* try to make it stay here, it might be important.
+ *
+ * If the current task on @p's runqueue is a non-DL task,
+ * and this task is bound on current runqueue, then try to
+ * see if we can wake this DL task up on a different runqueue,
*/
- if (unlikely(dl_task(curr)) &&
- (curr->nr_cpus_allowed < 2 ||
- !dl_entity_preempt(&p->dl, &curr->dl)) &&
- (p->nr_cpus_allowed > 1)) {
+ if (unlikely(curr->nr_cpus_allowed < 2) ||
+ unlikely(dl_task(curr) &&
+ !dl_entity_preempt(&p->dl, &curr->dl))) {
-- Steve
int target = find_later_rq(p);--
if (target != -1)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/