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:   Tue, 14 Feb 2017 08:42:43 +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,
        Luca Abeni <luca.abeni@...tannapisa.it>
Subject: Re: [PATCH] sched/deadline: Remove redundant code replenishing
 runtime

On Mon, Feb 13, 2017 at 03:24:55PM +0000, Juri Lelli wrote:
> > > > 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.
> > > 
> 
> What you mean by 'distorted'. AFAIU, we just want to replenish when
> needed. The instant of time when the task will eventually wake up it is
> something we cannot rely upon, and could introduce errors.
> 
> IIUC, your situation looks like the below

Exactly.

> 
>    oooo|-------------------vxxx^ooo
>        |                   |   |
>        |                   |   |
>     sleep/throttle         |   |
>                      r. timer  |
>    		           wakeup

Sorry for bothering you..

> The task gets throttled while going to sleep, when the replenishment
> timer fires you are proposing we do nothing and we actually replenishing
> using the wakeup rq_clock() as reference. My worry is that, by doing so,
> we make the task potentially loose some of its bandwidth, as we will
> have lost some time (the 3 x-es in the diagram above) when calculating
> its next dynamic deadline.

I meant, when we decide whether it's overflowed in dl_entiry_overflow(),
'right' might be smaller than 'left' because 't' is the time the 3 x-es
already passed.

Of course, here I assumed that runtime ~= 0 and deadline ~= rq_clock
when it was throttled, if scheduler works nicely.

> > > IMHO, it's neat to set its deadline and runtime when being woken up, in
> > > the case already passed its deadline. Am I wrong?
> > 
> > And I found that dl_entity_overflow() returns true and replenishes the
> > task unconditionally in update_dl_entity() again when the task is woken
> > up, because 'runtime / (deadline - t) > dl_runtime / dl_period' is true.
> > 
> 
> Why 'unconditionally'? It will postpone and replenish if the task is

Not exactly 'unconditially' if my assumption is broken. Sorry for
choosing a word that is not careful.

> going to overflow, if not, it will keep its runtime and deadline we set

I meant the task will be almost always considered 'overflow', as I
explained above. So it will be overwritten again when waking up the task
than keep what we set in timer callback.

> when the replenishment timer fired.