From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752653AbdB1NLc (ORCPT ); Tue, 28 Feb 2017 08:11:32 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:55230 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751872AbdB1NJg (ORCPT ); Tue, 28 Feb 2017 08:09:36 -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 Date: Tue, 28 Feb 2017 22:09:03 +0900 From: Byungchul Park To: Juri Lelli Cc: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, juri.lelli@gmail.com, rostedt@goodmis.org, kernel-team@lge.com Subject: Re: [PATCH v3] sched/deadline: Change the time to replenish runtime for sleep tasks Message-ID: <20170228130903.GF3817@X58A-UD3R> References: <1487830499-1691-1-git-send-email-byungchul.park@lge.com> <20170228113515.GM19665@e106622-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170228113515.GM19665@e106622-lin> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 28, 2017 at 11:35:15AM +0000, Juri Lelli wrote: > Hi, > > On 23/02/17 15:14, Byungchul Park wrote: > > Let's consider the following example. > > > > timeline : o...................o.........o.......o..o > > ^ ^ ^ ^ ^ > > | | | | | > > start | | | | > > original runtime | | | > > sleep with (-)runtime | | > > original deadline | > > wake up > > > > When this task is woken up, a negative runtime should be considered, > > which means that the task should get penalized when assigning runtime, > > becasue it already spent more than expected. Current code handles this > > by replenishing a runtime in hrtimer callback for deadline. But this > > approach has room for improvement: > > > > It will be replenished twice unnecessarily if the task sleeps for > > long time so that the deadline, assigned in the hrtimer callback, > > also passed. In other words, one happens in the callback and the > > other happens in update_dl_entiry() when waking it up. > > > > So force to replenish it for sleep tasks when waking it up. > > > > Signed-off-by: Byungchul Park > > --- > > kernel/sched/deadline.c | 13 ++++++------- > > 1 file changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > > index 27737f3..cb43ce9 100644 > > --- a/kernel/sched/deadline.c > > +++ b/kernel/sched/deadline.c > > @@ -498,8 +498,9 @@ static void update_dl_entity(struct sched_dl_entity *dl_se, > > struct dl_rq *dl_rq = dl_rq_of_se(dl_se); > > struct rq *rq = rq_of_dl_rq(dl_rq); > > > > - if (dl_time_before(dl_se->deadline, rq_clock(rq)) || > > - dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) { > > + if (dl_time_before(dl_se->deadline, rq_clock(rq))) > > + replenish_dl_entity(dl_se, pi_se); > > + else if (dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) { > > dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline; > > dl_se->runtime = pi_se->dl_runtime; > > } > > @@ -621,13 +622,11 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer *timer) > > * __dequeue_task_dl() > > * prev->on_rq = 0; > > * > > - * We can be both throttled and !queued. Replenish the counter > > - * but do not enqueue -- wait for our wakeup to do that. > > + * We can be both throttled and !queued. Wait for our wakeup to > > + * replenish runtime and enqueue p. > > */ > > - if (!task_on_rq_queued(p)) { > > - replenish_dl_entity(dl_se, dl_se); > > Hasn't this patch the same problem we discussed a couple of weeks ago? No. This patch solves the problem by calling replenish_dl_entity() when a dl task is woken up. The problem was that it cannot consider negative runtime if we replenish the task when it's woken up. So I made replenish_dl_entity() called even on wake-up path, instead of simple assignment. IMHO, this patch avoids double-replenishing properly, but adds additional condition on wake-up path to acheive it. To be honest, I don't think it's worth as I expected. Thank you, Byungchul > > https://marc.info/?l=linux-kernel&m=148699950802995 > > Thanks, > > - Juri