Re: [PATCH RFC] sched/deadline: support dl task migrate during cpu hotplug

From: Wanpeng Li
Date: Tue Nov 04 2014 - 08:31:09 EST


Hi Peter,
On 14/11/4 äå6:10, Peter Zijlstra wrote:
On Tue, Nov 04, 2014 at 04:23:45PM +0800, Wanpeng Li wrote:
On Tue, Nov 04, 2014 at 09:32:25AM +0100, Peter Zijlstra wrote:
On Tue, Nov 04, 2014 at 07:57:48AM +0800, Wanpeng Li wrote:
On Mon, Nov 03, 2014 at 11:41:11AM +0100, Peter Zijlstra wrote:
On Fri, Oct 31, 2014 at 03:28:17PM +0800, Wanpeng Li wrote:
So what is wrong with making dl_task_timer() deal with it? The timer
will still fire on the correct time, canceling it and or otherwise
messing with the CBS is wrong. Once it fires, all we need to do is
migrate it to another cpu (preferably one that is still online of course
:-).
Do you mean what I need to do is push the task to another cpu in dl_task_timer()
if rq is offline?
That does indeed appear to be the sensible fix to me.

In addition, what will happen if dl task can't preempt on
another cpu?
So if we find that the rq the task was on is no longer available, we
need to select a new rq, the 'right' rq would be the one running the
latest deadline.

If it cannot preempt the latest (running) deadline, it was not eligible
for running in the first place so no worries, right?
I think this will lead to this deadline task cannot running on any rqs any more.
If my understanding is not right, when it will be picked?
So you unconditionally place it on the rq with the latest deadline. If
it cannot preempt, at least its on an online cpu. It will get scheduled
whenever its deadline is one of the N earliest, with N the number of
online CPUs.

If something like this make sense?

(Will test it tomorrow and send out a formal one)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index f3d7776..dac33d1 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -553,6 +553,41 @@ again:
push_dl_task(rq);
#endif
}
+
+ /*
+ * So if we find that the rq the task was on is no longer
+ * available, we need to select a new rq, the 'right' rq
+ * would be the one running the latest deadline.
+ *
+ * If it cannot preempt, at least it's on an online cpu. It
+ * will get scheduled whenever its deadline is one of the N
+ * earliest, with N the number of online CPUs.
+ */
+
+ if (!rq->online) {
+ struct rq *latest_rq = NULL;
+ int cpu;
+ u64 dmin = LONG_MAX;
+
+ for_each_cpu(cpu, &p->cpus_allowed)
+ if (cpu_online(cpu) &&
+ cpu_rq(cpu)->dl.earliest_dl.curr < dmin) {
+ latest_rq = cpu_rq(cpu);
+ dmin = latest_rq->dl.earliest_dl.curr;
+ }
+
+ if (!latest_rq)
+ goto unlock;
+
+ raw_spin_lock(&latest_rq->lock);
+
+ deactivate_task(rq, p, 0);
+ set_task_cpu(p, latest_rq->cpu);
+ activate_task(latest_rq, p, 0);
+
+ raw_spin_unlock(&latest_rq->lock);
+ }
+
unlock:
raw_spin_unlock(&rq->lock);

Regards,
Wanpeng Li

--
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/

--
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/