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

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