Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758089AbbBEQBY (ORCPT ); Thu, 5 Feb 2015 11:01:24 -0500 Received: from m50-111.126.com ([123.125.50.111]:52371 "EHLO m50-111.126.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757927AbbBEQBT (ORCPT ); Thu, 5 Feb 2015 11:01:19 -0500 From: Xunlei Pang To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Steven Rostedt , Juri Lelli , Xunlei Pang Subject: [PATCH v2 2/2] sched/rt: Add check_preempt_equal_prio() logic in pick_next_task_rt() Date: Thu, 5 Feb 2015 23:59:34 +0800 Message-Id: <1423151974-22557-2-git-send-email-xlpang@126.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1423151974-22557-1-git-send-email-xlpang@126.com> References: <1423151974-22557-1-git-send-email-xlpang@126.com> X-CM-TRANSID: jtKowAC33y9vk9NUGrIRAQ--.742S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7Aw1DWrWfAFW7tFyDtF1UKFg_yoW8uF17pa nY934fua1DA3W2gw1Syr4fCr45Gw1fA3y5Jr97ta1jyw45Xa10qr13tF1ayFWjqr4kJaya qr4qy3y2kr1Du3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jT6wZUUUUU= X-Originating-IP: [210.21.223.3] X-CM-SenderInfo: p0ost0bj6rjloofrz/1tbimRmXv00vMKG3MgAAse Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2356 Lines: 65 From: Xunlei Pang check_preempt_curr() doesn't call sched_class::check_preempt_curr when the class of current is a higher level. So if there is a DL task running when doing this for RT, check_preempt_equal_prio() will definitely miss, which may result in some response latency for this RT task if it is pinned and there're some same-priority migratable rt tasks already queued. We should do the similar thing in select_task_rq_rt() when first picking rt tasks after running out of DL tasks. This patch tackles the issue by peeking the next rt task(RT1), and if find RT1 migratable, just requeue it to the tail of the rq using requeue_task_rt(rq, p, 0). In this way: - If there do have another rt task(RT2) with the same priority as RT1, RT2 will finally be picked as the running task. While RT1 will be pushed onto another cpu via RT1's post_schedule(), as RT1 is migratable. The difference from check_preempt_equal_prio() here is that we just don't care whether RT2 is migratable. - Otherwise, if there's no rt task with the same priority as RT1, RT1 will still be picked as the running task after the requeuing. Signed-off-by: Xunlei Pang --- kernel/sched/rt.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index b1ea9c0..17dcbfa 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1482,6 +1482,22 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev) put_prev_task(rq, prev); +#ifdef CONFIG_SMP + /* + * If there's a running higher class task, check_preempt_curr() + * doesn't invoke check_preempt_equal_prio() for rt tasks, so + * we can do the similar thing here. + */ + if (rq->rt.rt_nr_total > 1 && + (prev->sched_class == &dl_sched_class || + prev->sched_class == &stop_sched_class)) { + p = peek_next_task_rt(rq); + if (p->nr_cpus_allowed != 1 && + cpupri_find(&rq->rd->cpupri, p, NULL)) + requeue_task_rt(rq, p, 0); + } +#endif + p = _pick_next_task_rt(rq); /* The running task is never eligible for pushing */ -- 1.9.1 -- 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/