linux-kernel - Re: [PATCH] sched/deadline: Remove redundant code replenishing runtime

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:   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