mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Bristot de Oliveira <bristot@redhat.com>
To: Juri Lelli <juri.lelli@arm.com>, Luca Abeni <luca.abeni@santannapisa.it>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
	Mike Galbraith <efault@gmx.de>,
	Romulo Silva de Oliveira <romulo.deoliveira@ufsc.br>
Subject: Re: [PATCH 3/2] sched/deadline: Use deadline instead of period when calculating overflow
Date: Wed, 15 Feb 2017 14:33:04 +0100	[thread overview]
Message-ID: <0b3af651-ad0d-e74b-ea02-f8706ad13bbb@redhat.com> (raw)
In-Reply-To: <20170215125925.GD1368@e106622-lin>

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

  parent reply	other threads:[~2017-02-15 13:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 19:05 [PATCH V2 0/2] sched/deadline: Fixes for constrained deadline tasks Daniel Bristot de Oliveira
2017-02-13 19:05 ` [PATCH V2 1/2] sched/deadline: Replenishment timer should fire in the next period Daniel Bristot de Oliveira
2017-02-13 19:05 ` [PATCH V2 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline Daniel Bristot de Oliveira
2017-02-14 15:54   ` Tommaso Cucinotta
2017-02-14 17:31     ` Daniel Bristot de Oliveira
2017-02-14 19:33   ` Steven Rostedt
2017-02-14 19:28 ` [PATCH 3/2] sched/deadline: Use deadline instead of period when calculating overflow Steven Rostedt (VMware)
2017-02-14 22:49   ` luca abeni
2017-02-15  0:14     ` Steven Rostedt
2017-02-15  7:40       ` Luca Abeni
2017-02-15 10:29         ` Juri Lelli
2017-02-15 11:32           ` Peter Zijlstra
2017-02-15 12:31           ` Luca Abeni
2017-02-15 12:59             ` Juri Lelli
2017-02-15 13:13               ` Luca Abeni
2017-02-15 14:15                 ` Juri Lelli
2017-02-15 13:33               ` Daniel Bristot de Oliveira [this message]
2017-02-15 13:42                 ` Daniel Bristot de Oliveira
2017-02-15 14:09                   ` Steven Rostedt
2017-02-15 14:16                 ` Juri Lelli
2017-02-16 16:36                 ` Tommaso Cucinotta
2017-02-16 16:47                   ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b3af651-ad0d-e74b-ea02-f8706ad13bbb@redhat.com \
    --to=bristot@redhat.com \
    --cc=efault@gmx.de \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=romulo.deoliveira@ufsc.br \
    --cc=rostedt@goodmis.org \
    --cc=tommaso.cucinotta@sssup.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®