linux-kernel - Re: [PATCH 3/2] sched/deadline: Use deadline instead of period when calculating overflow

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: <0b3af651-ad0d-e74b-ea02-f8706ad13bbb@redhat.com>
Date:   Wed, 15 Feb 2017 14:33:04 +0100
From:   Daniel Bristot de Oliveira <bristot@...hat.com>
To:     Juri Lelli <juri.lelli@....com>,
        Luca Abeni <luca.abeni@...tannapisa.it>
Cc:     Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tommaso Cucinotta <tommaso.cucinotta@...up.it>,
        Mike Galbraith <efault@....de>,
        Romulo Silva de Oliveira <romulo.deoliveira@...c.br>
Subject: Re: [PATCH 3/2] sched/deadline: Use deadline instead of period when
 calculating overflow

On 02/15/2017 01:59 PM, Juri Lelli wrote:
> Actually, another thing that we noticed, talking on IRC with Peter, is
> that we seem to be replenishing differently on different occasions:

When a task is awakened (not by the replenishment timer), it is not
possible to know if the absolute deadline var stores the absolute
deadline of activation which took place in the instant
(current time) - dl_period.

Therefore, assuming the next deadline is one dl_deadline away from now
is correct.

IOW: that is a sporadic activation - the task is activated after at
least minimum inter-arrival time between activation/replenishment:

>  - on wakeup (if overflowing) we do
> 
>    dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
>    dl_se->runtime = pi_se->dl_runtime;

In the replenishment timer, it is known that the absolute deadline
instant of the previous activation is in the deadline var. So
putting the absolute deadline one dl_period away is correct [1].

Another point is that this case avoids creating time drift due
to latencies. For instance, in the case of a 1 ms delay of the timer
(interrupts disabled?), the wakeup replenishment would push the
absolute a relative deadline + 1 ms away from the previous deadline.

IOW: the replenishment timer makes the periodic case - a fixed time
offset from the previous activation/replenishment.

>  - when the replenishment timer fires (un-thottle and with runtime < 0)
> 
>    dl_se->deadline += pi_se->dl_period;
>    dl_se->runtime += pi_se->dl_runtime;

So I think it is correct. Am I missing something?

[1] For the sake of completeness:

- dl_se->deadline = Absolute deadline
- dl_se->dl_deadline = Relative deadline

the next absolute deadline is at:

dl_se->deadline = dl_next_period(dl_se) + dl_se->dl_deadline;

as dl_next_period(dl_se) is:

dl_se->deadline - dl_se->dl_deadline + dl_se->dl_period;

the next deadline is at:

dl_se->deadline = dl_se->deadline - dl_se->dl_deadline +
dl_se->dl_period + dl_se->dl_deadline

Which can be simplified to:

dl_se->deadline = dl_se->deadline += pi_se->dl_period;

because we have (- dl_se->dl_deadline) + dl_se->dl_deadline.

-- Daniel