All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Abeni <luca.abeni@santannapisa.it>
To: Juri Lelli <juri.lelli@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	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 13:31:36 +0100	[thread overview]
Message-ID: <20170215133136.664c1bfe@luca> (raw)
In-Reply-To: <20170215102919.GA1368@e106622-lin>

Hi Juri,

On Wed, 15 Feb 2017 10:29:19 +0000
Juri Lelli <juri.lelli@arm.com> wrote:
[...]
> > Ok, thanks; I think I can now see why this can result in a task
> > consuming more than the reserved utilisation. I still need some
> > time to convince me that "runtime / (deadline - t) > dl_runtime /
> > dl_deadline" is the correct check to use (in this case, shouldn't
> > we also change the admission test to use densities instead of
> > utilisations?) 
> 
> Right, this is what I was wondering as well, as dl_overflow()
> currently looks at the period. And I also have some recollection of
> this discussion happening already in the past, unfortunately it was
> not on the list.
> 
> That discussion started with the following patch
[...]
> that we then dediced not to propose since (note that these are just my
> memories of the dicussion, so everything it's up for further
> discussion, also in light of the problem highlighted by Daniel)
> 
>  - SCHED_DEADLINE, as the documentation says, does AC using
> utilization
>  - it is however true that a sufficient (but not necessary) test on
> UP for D_i != P_i cases is the one of my patch above
>  - we have agreed in the past that the kernel should only check that
> we don't cause "overload" in the system (which is still the case if we
>    consider utilizations), not "hard schedulability"
I remember a similar discussion; I think the decision about what to do
depends on what are the requirements: hard deadline guarantees (but in
this case global EDF is just a bad choice) or tardines no overload
guarantees?

My understanding was that the kernel guarantees that deadline tasks
will not starve non-deadline tasks, and that there is an upper bound
for the tardiness experienced by deadline tasks. If this understanding
is correct, then the current admission test is ok. But if I
misunderstood the purpose of the kernel admission test, then maybe your
patch is ok.

Then, it is important to keep the admission test consistent with the
checks performed in dl_entity_overflow() (but whatever we decide to do,
dl_entity_overflow() should be fixed).


				Luca

>  - also because on SMP systems "sum(WCET_i / min{D_i, P_i}) <= M"
>    doesn't guarantee much more than the test base on P_i only (there
> not seem to be many/any papers around considering the D_i != P_i case
> on SMP actually)
>  - basically the patch above would only matter for the UP/partitioned
>    cases
> 
> Thoughts?
> 
> Thanks,
> 
> - Juri

  parent reply	other threads:[~2017-02-15 12:31 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 [this message]
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
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=20170215133136.664c1bfe@luca \
    --to=luca.abeni@santannapisa.it \
    --cc=bristot@redhat.com \
    --cc=efault@gmx.de \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.