On Tue, 4 Nov 2014 19:13:04 +0800 "pang.xunlei" <[email protected]> wrote:
> When selecting the cpu for a waking DL task, if curr is a non-DL > 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 <[email protected]> > --- > 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; > + This looks fine, and I'm wondering if we shouldn't just move this into 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) > 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))) { This has the same issue as the rt.c change. -- 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
