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]

Message-ID: <20170214020641.GP16086@X58A-UD3R>
Date:   Tue, 14 Feb 2017 11:06:41 +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 Tue, Feb 14, 2017 at 08:42:43AM +0900, Byungchul Park wrote:
> 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.

I don't want to argue strongly, keeping current code unchanged is ok.
I just wanted to say it will be replenished twice in most cases if:

   1. The task was throttled and passed its deadline while sleeping.

Of course, it also depends on how much negative runtime it had when
throttled. Sorry for bothering you and thanks for explaining it.