From: Andrea Bastoni <bastoni@cs.unc.edu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Bjoern Brandenburg <bbb@email.unc.edu>,
Raistlin <raistlin@linux.it>,
linux-kernel <linux-kernel@vger.kernel.org>,
Song Yuan <song.yuan@ericsson.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Nicola Manica <nicola.manica@disi.unitn.it>,
Luca Abeni <lucabe72@email.it>,
Claudio Scordino <claudio@evidence.eu.com>,
Harald Gustafsson <harald.gustafsson@ericsson.com>,
Giuseppe Lipari <lipari@retis.sssup.it>
Subject: Re: periods and deadlines in SCHED_DEADLINE
Date: Tue, 03 Aug 2010 23:52:35 -0400 [thread overview]
Message-ID: <4C58E403.6060209@cs.unc.edu> (raw)
In-Reply-To: <1280828475.1923.444.camel@laptop>
On 08/03/2010 05:41 AM, Peter Zijlstra wrote:
> On Sun, 2010-07-11 at 08:42 +0200, Bjoern Brandenburg wrote:
>>
>> If you want to do G-EDF with limited and different budgets on each CPU
>> (e.g., G-EDF tasks may only run for 100 out of 1000 ms on CPU 0, but
>> for 400 out of 1000 ms on CPU 1), then you are entering the domain of
>> restricted-supply scheduling, which is significantly more complicated
>> to analyze (see [1,2]).
>
> Without having looked at the refs, won't the soft case still have
> bounded tardiness? Since the boundedness property mostly depends on
> u<=1, that is, as long as we can always run everything within the
> available time we won't start drifting.
Yes, the soft case will still have bounded tardiness (see [2]), although the reason is more
related to the fact that priorities are defined by deadlines, than to U<=1.
Anyway, both hard and soft real-time cases become very difficult to analyze if limited/different
budgets are allowed on each CPU.
>> As far as I know there is no exiting analysis for "almost G-EDF",
>> i.e., the case where each task may only migrate among a subset of the
>> processors (= affinity masks), except for the special case of
>> clustered EDF (C-EDF), wherein the subsets of processors are
>> non-overlapping.
>
> Right, affinity masks are a pain, hence I proposed to limit that to
> either 1 cpu (yielding fully paritioned) or the full cluster.
I'm not sure I get what you mean by "full cluster". With G-EDF-like scheduling policies it only
makes sense to cluster cores around some memory level (cache Lx, NUMA node...), as the idea is
to reduce the cost of a task migration among cores. Depending on the workload, a higher (lower)
level of clustering may perform better.
A "full cluster" therefore should be created around some memory level. But if a socket has, for
example, two level of caches (L2 + L3) and a "full cluster" forces to select all cores in the
socket (first hierarchy level in cpusets), we miss the possibility to cluster the cores that
shares the L2 (and this configuration may lead better performance). In these clusters the
processors are _non-overlapping_.
Instead, if you want to use the cpuset + affinity to define possibly _overlapping_ clusters (or
containers, or servers) to support different budgets on each CPU (something similar to cgroup,
see [1,3]), forcing only two configuration (single cpu/full cluster) may be restrictive.
Thanks,
- Andrea
[3] H. Leontyev and J. Anderson, " A Hierarchical Multiprocessor Bandwidth Reservation Scheme
with Timing Guarantees", Real-Time Systems, Volume 43, Number 1, pp. 60-92, September 2009.
http://www.cs.unc.edu/~anderson/papers/rtj09b.pdf
--
Andrea Bastoni
Visiting Ph.D. Student
Dept. of Computer Science
University of North Carolina at Chapel Hill
http://www.sprg.uniroma2.it/home/bastoni/
next prev parent reply other threads:[~2010-08-04 4:38 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 13:38 periods and deadlines in SCHED_DEADLINE Raistlin
2010-07-09 14:18 ` Peter Zijlstra
2010-07-09 14:51 ` Bjoern Brandenburg
2010-07-09 16:35 ` Peter Zijlstra
2010-07-10 9:01 ` Raistlin
2010-07-10 10:28 ` Peter Zijlstra
2010-07-10 14:49 ` Raistlin
2010-07-11 6:42 ` Bjoern Brandenburg
2010-08-03 9:41 ` Peter Zijlstra
2010-08-04 3:52 ` Andrea Bastoni [this message]
2010-08-04 7:14 ` Peter Zijlstra
2010-08-04 5:18 ` Bjoern Brandenburg
2010-08-03 9:46 ` Peter Zijlstra
2010-08-04 3:53 ` Andrea Bastoni
2010-08-04 5:02 ` Bjoern Brandenburg
2010-07-10 7:08 ` Raistlin
2010-07-11 6:46 ` Bjoern Brandenburg
2010-08-03 8:16 ` Peter Zijlstra
2010-08-03 11:42 ` Gregory Haskins
2010-08-04 6:30 ` Bjoern Brandenburg
2010-07-09 14:24 ` Peter Zijlstra
2010-07-10 7:11 ` Luca Abeni
2010-07-10 10:36 ` Peter Zijlstra
2010-07-11 6:12 ` Bjoern Brandenburg
2010-07-09 14:30 ` Peter Zijlstra
2010-07-10 9:14 ` Raistlin
2010-07-10 17:19 ` Harald Gustafsson
2010-07-10 18:31 ` Peter Zijlstra
2010-07-10 20:08 ` Harald Gustafsson
2010-07-10 21:52 ` Raistlin
2010-07-11 5:41 ` Harald Gustafsson
2010-07-11 7:32 ` Bjoern Brandenburg
2010-07-12 10:21 ` Harald Gustafsson
2010-08-04 5:55 ` Bjoern Brandenburg
2010-08-02 19:34 ` Peter Zijlstra
2010-08-04 4:44 ` Bjoern Brandenburg
2010-07-09 14:32 ` Peter Zijlstra
2010-07-10 7:50 ` Raistlin
2010-07-10 15:11 ` Peter Zijlstra
2010-07-10 17:29 ` Harald Gustafsson
2010-07-11 6:15 ` Bjoern Brandenburg
2010-07-10 7:09 ` Luca Abeni
2010-07-10 9:20 ` Raistlin
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=4C58E403.6060209@cs.unc.edu \
--to=bastoni@cs.unc.edu \
--cc=bbb@email.unc.edu \
--cc=claudio@evidence.eu.com \
--cc=dmitry.adamushko@gmail.com \
--cc=harald.gustafsson@ericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lipari@retis.sssup.it \
--cc=lucabe72@email.it \
--cc=nicola.manica@disi.unitn.it \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
--cc=song.yuan@ericsson.com \
--cc=tglx@linutronix.de \
/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