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]
Message-ID: <20170213023009.GF16086@X58A-UD3R>
Date:   Mon, 13 Feb 2017 11:30:09 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Juri Lelli <juri.lelli@....com>
Cc:     peterz@...radead.org, mingo@...nel.org,
        linux-kernel@...r.kernel.org, tkhai@...dex.ru
Subject: Re: [PATCH] sched/deadline: Remove redundant code replenishing
 runtime

On Fri, Feb 10, 2017 at 01:39:33PM +0000, Juri Lelli wrote:
> Hi,
> 
> On 10/02/17 18:11, Byungchul Park wrote:
> > For a task passing its deadline while !rq, it will be replenished
> > in the following path because dl_se->deadline < rq_lock.
> > 
> >    enqueue_dl_entity(ENQUEUE_WAKEUP)
> >       update_dl_entity
> > 
> > Therefore, code replenishing it in the timer callback in the case is
> > unnecessary. This is not for enhancing performance but just for removing
> > a redundant code.
> > 
> > Signed-off-by: Byungchul Park <byungchul.park@....com>
> > ---
> >  kernel/sched/deadline.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 27737f3..9c77696 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -624,10 +624,8 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer *timer)
> >  	 * We can be both throttled and !queued. Replenish the counter
> >  	 * but do not enqueue -- wait for our wakeup to do that.
> >  	 */
> > -	if (!task_on_rq_queued(p)) {
> > -		replenish_dl_entity(dl_se, dl_se);
> 
> I think we actually want to replenish and set the next deadline at this
> point of time, not the one that we get when the task will eventually wake up.

Hello juri,

But I wonder if it's meaningful to set a next deadline for a 'sleeping
task', which, rather, could be worse because its bandwidth might be
distorted at the time it's woken up.

IMHO, it's neat to set its deadline and runtime when being woken up, in
the case already passed its deadline. Am I wrong?

Thank you,
Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ