From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751188AbdBWDlA (ORCPT ); Wed, 22 Feb 2017 22:41:00 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:51003 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750837AbdBWDkt (ORCPT ); Wed, 22 Feb 2017 22:40:49 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com From: Byungchul Park To: peterz@infradead.org, mingo@kernel.org Cc: linux-kernel@vger.kernel.org, juri.lelli@gmail.com, rostedt@goodmis.org, kernel-team@lge.com Subject: [PATCH v2 1/2] sched/deadline: Factor out the actual work replenishing runtime Date: Thu, 23 Feb 2017 12:10:37 +0900 Message-Id: <1487819438-3364-1-git-send-email-byungchul.park@lge.com> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The actual work replenishing runtime can also be used by other than replenish_dl_entiry(). So factor this out into a separate function so that others can use it. Signed-off-by: Byungchul Park --- kernel/sched/deadline.c | 59 ++++++++++++++++++++++++++++--------------------- 1 file changed, 34 insertions(+), 25 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 27737f3..69e3fbb 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -359,6 +359,39 @@ static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) dl_se->runtime = dl_se->dl_runtime; } +static void __replenish_dl_entity(struct sched_dl_entity *dl_se, + struct sched_dl_entity *pi_se) +{ + struct dl_rq *dl_rq = dl_rq_of_se(dl_se); + struct rq *rq = rq_of_dl_rq(dl_rq); + + /* + * We keep moving the deadline away until we get some + * available runtime for the entity. This ensures correct + * handling of situations where the runtime overrun is + * arbitrary large. + */ + while (dl_se->runtime <= 0) { + dl_se->deadline += pi_se->dl_period; + dl_se->runtime += pi_se->dl_runtime; + } + + /* + * At this point, the deadline really should be "in + * the future" with respect to rq->clock. If it's + * not, we are, for some reason, lagging too much! + * Anyway, after having warn userspace abut that, + * we still try to keep the things running by + * resetting the deadline and the budget of the + * entity. + */ + if (dl_time_before(dl_se->deadline, rq_clock(rq))) { + printk_deferred_once("sched: DL replenish lagged too much\n"); + dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline; + dl_se->runtime = pi_se->dl_runtime; + } +} + /* * Pure Earliest Deadline First (EDF) scheduling does not deal with the * possibility of a entity lasting more than what it declared, and thus @@ -397,31 +430,7 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se, if (dl_se->dl_yielded && dl_se->runtime > 0) dl_se->runtime = 0; - /* - * We keep moving the deadline away until we get some - * available runtime for the entity. This ensures correct - * handling of situations where the runtime overrun is - * arbitrary large. - */ - while (dl_se->runtime <= 0) { - dl_se->deadline += pi_se->dl_period; - dl_se->runtime += pi_se->dl_runtime; - } - - /* - * At this point, the deadline really should be "in - * the future" with respect to rq->clock. If it's - * not, we are, for some reason, lagging too much! - * Anyway, after having warn userspace abut that, - * we still try to keep the things running by - * resetting the deadline and the budget of the - * entity. - */ - if (dl_time_before(dl_se->deadline, rq_clock(rq))) { - printk_deferred_once("sched: DL replenish lagged too much\n"); - dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline; - dl_se->runtime = pi_se->dl_runtime; - } + __replenish_dl_entity(dl_se, pi_se); if (dl_se->dl_yielded) dl_se->dl_yielded = 0; -- 1.9.1