From: Juri Lelli <juri.lelli@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: luca abeni <luca.abeni@unitn.it>,
linux-kernel@vger.kernel.org,
Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
Juri Lelli <juri.lelli@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrea Parri <parri.andrea@gmail.com>,
giuseppe lipari <giuseppe.lipari@lsv.ens-cachan.fr>,
Claudio Scordino <claudio@evidence.eu.com>
Subject: Re: About group scheduling for SCHED_DEADLINE
Date: Tue, 18 Oct 2016 10:43:24 +0100 [thread overview]
Message-ID: <20161018094324.GJ25339@e106622-lin> (raw)
In-Reply-To: <20161017082503.GY3568@worktop.programming.kicks-ass.net>
Hi,
On 17/10/16 10:25, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 08:38:57AM +0200, luca abeni wrote:
>
> > > Yes, there currently is no existing schedulability analysis for
> > > multi-processor EDF with random affinities (as far as I know)
> > Correction: it looks like I was wrong, and the schedulability of
> > multi-processor EDF with arbitrary affinities has already been analysed
> > in
> > A. Gujarati, F. Cerqueira, and B. Brandenburg, “Multiprocessor
> > Real-Time Scheduling with Arbitrary Processor Affinities: From Practice
> > to Theory”, Real- Time Systems, Volume 51, Issue 4, pp. 440–483.
> > Springer Verlag, 2015
> > (see https://www.mpi-sws.org/~bbb/papers/).
> >
> > Thanks to Giuseppe Lipari for pointing me to this paper.
>
> Ooh, shiny. Let me go read that.
>
Yeah, I should read that again (last time I remember headaches :).
> > So, having DL tasks with arbitrary affinities is not a big problem from
> > the theoretical point of view... The only issue is that the
> > utilisation-based admission test that is currently implemented in the
> > kernel does not work (and given the complexity of the analysis I think
> > it is better not to perform it in the kernel :)
>
> So the problem with doing admission control out of the kernel is that
> then all the guarantees and resource control the kernel should provide
> are out the window, and we're back to all the reasons why SCHED_FIFO is
> a horrible horrible scheduling policy.
>
I agree that we must have admission control in the kernel, but I don't
see why disabling such AC and let userspace perform more complex
calculations would make scheduler policies bogus. What we have today
(modulo fixes and possible small improvements) seems a sane and simple
default admission test to me. If userspace (and here I think of some
middleware controller type of thing more than a simple user) has
knowledge (and root privileges) and needs to perform more complex tests,
it can disable the kernel AC, but still rely on resource control
mechanisms provided by the kernel to provide guarantees (such thing is
still not achievable with FIFO).
Best,
- Juri
next prev parent reply other threads:[~2016-10-18 9:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-09 19:39 About group scheduling for SCHED_DEADLINE Luca Abeni
2016-10-10 10:15 ` Peter Zijlstra
2016-10-10 11:08 ` Peter Zijlstra
2016-10-16 19:40 ` Luca Abeni
2016-10-17 6:38 ` luca abeni
2016-10-17 8:25 ` Peter Zijlstra
2016-10-18 9:43 ` Juri Lelli [this message]
2016-10-10 12:04 ` Peter Zijlstra
2016-10-16 19:34 ` Luca Abeni
2016-10-17 10:52 ` Peter Zijlstra
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=20161018094324.GJ25339@e106622-lin \
--to=juri.lelli@arm.com \
--cc=claudio@evidence.eu.com \
--cc=giuseppe.lipari@lsv.ens-cachan.fr \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@unitn.it \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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