[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <008a01d28d83$8d0605a0$a71210e0$@lge.com>
Date: Thu, 23 Feb 2017 12:18:48 +0900
From: "byungchul.park" <byungchul.park@....com>
To: <peterz@...radead.org>, <mingo@...nel.org>
Cc: <linux-kernel@...r.kernel.org>, <juri.lelli@...il.com>,
<rostedt@...dmis.org>, <kernel-team@....com>
Subject: RE: [PATCH v2 2/2] sched/deadline: Change the way to replenish runtime for sleep tasks
> -----Original Message-----
> From: Byungchul Park [mailto:byungchul.park@....com]
> Sent: Thursday, February 23, 2017 12:11 PM
> To: peterz@...radead.org; mingo@...nel.org
> Cc: linux-kernel@...r.kernel.org; juri.lelli@...il.com;
> rostedt@...dmis.org; kernel-team@....com
> Subject: [PATCH v2 2/2] sched/deadline: Change the way to replenish
> runtime for sleep tasks
>
> 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 in two ways:
>
> 1. No need to keep the hrtimer for a sleep task because it can be
> handled when waking it up.
>
> 2. 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 try to cancel the hrtimer for a sleep task and make all these things
> handled when waking it up.
>
> Signed-off-by: Byungchul Park <byungchul.park@....com>
> ---
> kernel/sched/deadline.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 69e3fbb..b59ee7b 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -507,8 +507,10 @@ 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);
> +
> + 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;
> }
> @@ -981,6 +983,9 @@ static void dequeue_task_dl(struct rq *rq, struct
> task_struct *p, int flags)
> {
> update_curr_dl(rq);
> __dequeue_task_dl(rq, p, flags);
> +
> + if (flags & DEQUEUE_SLEEP)
> + hrtimer_try_to_cancel(&p->dl.dl_timer);
Sorry. I found I might have made a mistake. I might have to re-start the
timer when waking it up if necessary. Let me think more.
> }
>
> /*
> --
> 1.9.1
Powered by blists - more mailing lists