lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ