| Message ID | 1415099585-31174-2-git-send-email-pang.xunlei@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Tue, 4 Nov 2014 19:13:01 +0800 "pang.xunlei" <pang.xunlei@linaro.org> wrote: > When selecting the cpu for a waking RT task, if curr is a non-RT > task which is bound only on this cpu, then we can give it a chance > to select a different cpu(definitely an idle cpu if existing) for > the RT task to avoid curr starving. Absolutely not! An RT task doesn't give a crap if a non RT task is bound to a CPU or not. We are not going to migrate an RT task to be nice to a bounded non-RT task. Migration is not cheap. It causes cache misses and TLB flushes. This is not something that should be taken lightly. Nack -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 4 November 2014 20:52, Steven Rostedt <rostedt@goodmis.org> wrote: > On Tue, 4 Nov 2014 19:13:01 +0800 > "pang.xunlei" <pang.xunlei@linaro.org> wrote: > >> When selecting the cpu for a waking RT task, if curr is a non-RT >> task which is bound only on this cpu, then we can give it a chance >> to select a different cpu(definitely an idle cpu if existing) for >> the RT task to avoid curr starving. > > Absolutely not! An RT task doesn't give a crap if a non RT task is > bound to a CPU or not. We are not going to migrate an RT task to be > nice to a bounded non-RT task. > > Migration is not cheap. It causes cache misses and TLB flushes. This is > not something that should be taken lightly. Ok, thanks! But I think the PUSH operation optimized by the former patch is reasonable, since PUSH itselft does involve the Migration. Do I miss something? > > Nack > > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, 4 Nov 2014 22:29:24 +0800 "pang.xunlei" <pang.xunlei@linaro.org> wrote: > > Migration is not cheap. It causes cache misses and TLB flushes. This is > > not something that should be taken lightly. > Ok, thanks! > But I think the PUSH operation optimized by the former patch is reasonable, > since PUSH itselft does involve the Migration. Do I miss something? For the first patch you may be right, but I want to think about it some more. I want to make sure we are not adding any other type of overhead with the extra calls. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 4 November 2014 22:47, Steven Rostedt <rostedt@goodmis.org> wrote: > On Tue, 4 Nov 2014 22:29:24 +0800 > "pang.xunlei" <pang.xunlei@linaro.org> wrote: > > >> > Migration is not cheap. It causes cache misses and TLB flushes. This is >> > not something that should be taken lightly. >> Ok, thanks! >> But I think the PUSH operation optimized by the former patch is reasonable, >> since PUSH itselft does involve the Migration. Do I miss something? > > For the first patch you may be right, but I want to think about it some > more. I want to make sure we are not adding any other type of overhead > with the extra calls. Yes, this may cause some overhead/latency in idle especially its exit stage, if that can't be accepted, I think it can also be done just in find_lowest_rq() after cpupri_find(), we can modify cpupri_find() for example to return a pri_to_cpu[] index plus one instead of 1, then if the return index equals CPUPRI_NORMAL+1, then iterate the "lowest_mask" with something like cpu_idle() judgement to select the idle cpu. > > -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index da6922e..dc1f7f0 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1340,6 +1340,11 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags) * runqueue. Otherwise simply start this RT task * on its current runqueue. * + * If the current task on @p's runqueue is a non-RT task, + * and this task is bound on current runqueue, then try to + * see if we can wake this RT task up on a different runqueue, + * we will definitely find an idle cpu if there is any. + * * We want to avoid overloading runqueues. If the woken * task is a higher priority, then it will stay on this CPU * and the lower prio task should be moved to another CPU. @@ -1356,9 +1361,8 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags) * This test is optimistic, if we get it wrong the load-balancer * will have to sort it out. */ - if (curr && unlikely(rt_task(curr)) && - (curr->nr_cpus_allowed < 2 || - curr->prio <= p->prio)) { + if (curr && unlikely(curr->nr_cpus_allowed < 2 || + curr->prio <= p->prio)) { int target = find_lowest_rq(p); if (target != -1)
When selecting the cpu for a waking RT task, if curr is a non-RT task which is bound only on this cpu, then we can give it a chance to select a different cpu(definitely an idle cpu if existing) for the RT task to avoid curr starving. Signed-off-by: pang.xunlei <pang.xunlei@linaro.org> --- kernel/sched/rt.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)