On 28/01/14 09:31, Peter Zijlstra wrote:
>> Exactly. I can remember also a huge period might be harmful, because with it
>> even a tiny utilization may lead to a big runtime that starves the whole non
>> RT tasks for a significant time.
>
> Another way to solve that is with explicit slack time
On 01/27/2014 11:29 PM, Luca Abeni wrote:
> Hi Steven,
>
> On Mon, 27 Jan 2014 12:09:38 -0500
> Steven Rostedt wrote:
> [...]
Lets take a case where deadline == period. It seems that the above
would be true any time there was any delay to starting the task
or the task was
On Fri, Jan 24, 2014 at 10:08:35AM +, Tommaso Cucinotta wrote:
> > We should also again talk about what it would take to allow
> > unprivileged access to SCHED_DEADLINE. The things I can remember are the
> > obvious cap on utilization and a minimum period -- the latter so that we
> > don't DoS
On Fri, Jan 24, 2014 at 10:08:35AM +, Tommaso Cucinotta wrote:
We should also again talk about what it would take to allow
unprivileged access to SCHED_DEADLINE. The things I can remember are the
obvious cap on utilization and a minimum period -- the latter so that we
don't DoS the
On 01/27/2014 11:29 PM, Luca Abeni wrote:
Hi Steven,
On Mon, 27 Jan 2014 12:09:38 -0500
Steven Rostedt rost...@goodmis.org wrote:
[...]
Lets take a case where deadline == period. It seems that the above
would be true any time there was any delay to starting the task
or the task was
On 28/01/14 09:31, Peter Zijlstra wrote:
Exactly. I can remember also a huge period might be harmful, because with it
even a tiny utilization may lead to a big runtime that starves the whole non
RT tasks for a significant time.
Another way to solve that is with explicit slack time
Hi Steven,
On Mon, 27 Jan 2014 12:09:38 -0500
Steven Rostedt wrote:
[...]
> > > Lets take a case where deadline == period. It seems that the above
> > > would be true any time there was any delay to starting the task
> > > or the task was interrupted by another SCHED_DEADLINE task.
> > Not sure
On Mon, 27 Jan 2014 17:56:07 +0100
Luca Abeni wrote:
> > > +
> > > +then, if the scheduling deadline is smaller than the current
> > > time, or
> > > +this condition is verified, the scheduling deadline and the
> > > +current budget are re-initialised as
> > > +
> > > +
Hi Steven,
On Mon, 27 Jan 2014 10:35:56 -0500
Steven Rostedt wrote:
[...]
> > + to be executed first. Thanks to this feature, also tasks that do
> > not
> > + strictly comply with the "traditional" real-time task model (see
> > Section 3)
> > + can effectively use the new policy.
> > +
> > + In
On Mon, 27 Jan 2014 12:20:15 +0100
Juri Lelli wrote:
> +
> +2. Scheduling algorithm
> +==
> +
> + SCHED_DEADLINE uses three parameters, named "runtime", "period", and
> + "deadline" to schedule tasks. A SCHED_DEADLINE task is guaranteed to receive
> + "runtime" microseconds of
On 01/27/2014 01:40 PM, Henrik Austad wrote:
[...]
Current runtime: time spent running _this_ period? or is _remaining_
runtime this period? I get the feeling it's the latter.
So, roughly, it is the ration
remaining_runtime / relative_time_to_deadline
which needs to be greater than the
On Mon, Jan 27, 2014 at 01:30:42PM +0100, Luca Abeni wrote:
> Hi Henrik,
>
> On 01/27/2014 12:53 PM, Henrik Austad wrote:
> [...]
> >>+ In more details, the CBS algorithm assigns scheduling deadlines to
> >>+ tasks in the following way:
> >>+
> >>+ - Each SCHED_DEADLINE task is characterised by
Hi Henrik,
On 01/27/2014 12:53 PM, Henrik Austad wrote:
[...]
+ In more details, the CBS algorithm assigns scheduling deadlines to
+ tasks in the following way:
+
+ - Each SCHED_DEADLINE task is characterised by the "runtime",
+"deadline", and "period" parameters;
+
+ - The state of the
On Mon, Jan 27, 2014 at 12:20:15PM +0100, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add in Documentation/scheduler/ some hints about the design
> choices, the usage and the future possible developments of the
> sched_dl scheduling class and of the SCHED_DEADLINE policy.
>
> Cc:
On 01/27/2014 12:20 PM, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add in Documentation/scheduler/ some hints about the design
> choices, the usage and the future possible developments of the
> sched_dl scheduling class and of the SCHED_DEADLINE policy.
>
> Cc: bruce.ashfi...@windriver.com
>
On 01/27/2014 12:20 PM, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
Cc:
On Mon, Jan 27, 2014 at 12:20:15PM +0100, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
Cc:
Hi Henrik,
On 01/27/2014 12:53 PM, Henrik Austad wrote:
[...]
+ In more details, the CBS algorithm assigns scheduling deadlines to
+ tasks in the following way:
+
+ - Each SCHED_DEADLINE task is characterised by the runtime,
+deadline, and period parameters;
+
+ - The state of the task is
On Mon, Jan 27, 2014 at 01:30:42PM +0100, Luca Abeni wrote:
Hi Henrik,
On 01/27/2014 12:53 PM, Henrik Austad wrote:
[...]
+ In more details, the CBS algorithm assigns scheduling deadlines to
+ tasks in the following way:
+
+ - Each SCHED_DEADLINE task is characterised by the runtime,
+
On 01/27/2014 01:40 PM, Henrik Austad wrote:
[...]
Current runtime: time spent running _this_ period? or is _remaining_
runtime this period? I get the feeling it's the latter.
So, roughly, it is the ration
remaining_runtime / relative_time_to_deadline
which needs to be greater than the
On Mon, 27 Jan 2014 12:20:15 +0100
Juri Lelli juri.le...@gmail.com wrote:
+
+2. Scheduling algorithm
+==
+
+ SCHED_DEADLINE uses three parameters, named runtime, period, and
+ deadline to schedule tasks. A SCHED_DEADLINE task is guaranteed to receive
+ runtime microseconds
Hi Steven,
On Mon, 27 Jan 2014 10:35:56 -0500
Steven Rostedt rost...@goodmis.org wrote:
[...]
+ to be executed first. Thanks to this feature, also tasks that do
not
+ strictly comply with the traditional real-time task model (see
Section 3)
+ can effectively use the new policy.
+
+
On Mon, 27 Jan 2014 17:56:07 +0100
Luca Abeni luca.ab...@unitn.it wrote:
+
+then, if the scheduling deadline is smaller than the current
time, or
+this condition is verified, the scheduling deadline and the
+current budget are re-initialised as
+
+
Hi Steven,
On Mon, 27 Jan 2014 12:09:38 -0500
Steven Rostedt rost...@goodmis.org wrote:
[...]
Lets take a case where deadline == period. It seems that the above
would be true any time there was any delay to starting the task
or the task was interrupted by another SCHED_DEADLINE task.
On 22/01/14 13:51, Peter Zijlstra wrote:
>>> Another possibly extension; one proposed by Ingo; is to demote tasks to
>>> SCHED_OTHER once they exceed their budget instead of the full block they
>>> get now -- we could possibly call this SCHED_FLAG_DL_CBS_SOFT or such.
Soft reservations are also
On 22/01/14 13:51, Peter Zijlstra wrote:
Another possibly extension; one proposed by Ingo; is to demote tasks to
SCHED_OTHER once they exceed their budget instead of the full block they
get now -- we could possibly call this SCHED_FLAG_DL_CBS_SOFT or such.
Soft reservations are also very
On Wed, Jan 22, 2014 at 02:03:18PM +0100, Luca Abeni wrote:
> >At which point I feel obliged to mention the work Jim did on statistical
> >bounded tardiness and a potential future option:
> >SCHED_FLAG_DL_AVG_RUNTIME, where we would allow tasks to somewhat exceed
> >their runtime budget provided
Hi,
On 01/21/2014 02:55 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
- During the execution of a job, the task might invoke a blocking system call,
and block... When it wakes up, it is still in the
Hi,
On 01/21/2014 02:55 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
- During the execution of a job, the task might invoke a blocking system call,
and block... When it wakes up, it is still in the
On Wed, Jan 22, 2014 at 02:03:18PM +0100, Luca Abeni wrote:
At which point I feel obliged to mention the work Jim did on statistical
bounded tardiness and a potential future option:
SCHED_FLAG_DL_AVG_RUNTIME, where we would allow tasks to somewhat exceed
their runtime budget provided that they
On Tue, 21 Jan 2014 14:55:59 +0100
Peter Zijlstra wrote:
> > >I would strongly urge you not to use that as an example, because its
> > >dead wrong design. An RT thread (be it RR,FIFO or DL) should _NEVER_ do
> > >blocking IO.
> > Well, but it does happen in reality :)
>
> Yeah, I know, my
On Mon, 20 Jan 2014 12:46:06 +0100
Peter Zijlstra wrote:
> > activates - released?
> >
> > Since real-time papers from different rt-campus around the academia insist
> > on using *slightly* different terminology, perhaps add a short dictionary
> > for some of the more common terms?
>
> Oh
On 01/21/2014 02:55 PM, Peter Zijlstra wrote:
> On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
>> On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
>
- During the execution of a job, the task might invoke a blocking system
call,
and block... When it wakes up, it is
On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
> On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
> >>- During the execution of a job, the task might invoke a blocking system
> >>call,
> >> and block... When it wakes up, it is still in the same job (decoding the
> >> same
> >>
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:
In a system, we typically look at a set of tasks. In Linux-kernel
terminology, a particular task is normally a thread. When a thread is
ready to run, we say that a *job* of that task is
On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:
> >In a system, we typically look at a set of tasks. In Linux-kernel
> >terminology, a particular task is normally a thread. When a thread is
> >ready to run, we say that a *job* of that task is running.
> This would be true in the
Ok,
I'd say that we need to re-write parts of the document, as we need more
consensus about terms and better explain to users what SCHED_DEADLINE can be
used for, and the type of guarantees it can provide. I'll try to do this with
Luca, taking into account Henrik's points.
Thanks,
- Juri
On
On 01/21/2014 11:20 AM, Henrik Austad wrote:
On Mon, Jan 20, 2014 at 02:39:29PM +0100, Luca Abeni wrote:
Hi all,
On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic
On Mon, Jan 20, 2014 at 12:24:42PM +0100, Henrik Austad wrote:
> On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
> > From: Dario Faggioli
> >
> > Add in Documentation/scheduler/ some hints about the design
> > choices, the usage and the future possible developments of the
> >
On Mon, Jan 20, 2014 at 02:39:29PM +0100, Luca Abeni wrote:
> Hi all,
>
> On 01/20/2014 02:16 PM, Henrik Austad wrote:
> [...]
> + The typical -deadline task is composed of a computation phase (instance)
> + which is activated on a periodic or sporadic fashion. The expected
>
On Mon, Jan 20, 2014 at 02:39:29PM +0100, Luca Abeni wrote:
Hi all,
On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic fashion. The expected
(maximum)
+ duration of
On Mon, Jan 20, 2014 at 12:24:42PM +0100, Henrik Austad wrote:
On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
On 01/21/2014 11:20 AM, Henrik Austad wrote:
On Mon, Jan 20, 2014 at 02:39:29PM +0100, Luca Abeni wrote:
Hi all,
On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic
Ok,
I'd say that we need to re-write parts of the document, as we need more
consensus about terms and better explain to users what SCHED_DEADLINE can be
used for, and the type of guarantees it can provide. I'll try to do this with
Luca, taking into account Henrik's points.
Thanks,
- Juri
On
On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:
In a system, we typically look at a set of tasks. In Linux-kernel
terminology, a particular task is normally a thread. When a thread is
ready to run, we say that a *job* of that task is running.
This would be true in the original
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 12:35:27PM +0100, Luca Abeni wrote:
In a system, we typically look at a set of tasks. In Linux-kernel
terminology, a particular task is normally a thread. When a thread is
ready to run, we say that a *job* of that task is
On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
- During the execution of a job, the task might invoke a blocking system
call,
and block... When it wakes up, it is still in the same job (decoding the
same
video frame), and
On 01/21/2014 02:55 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote:
On 01/21/2014 01:33 PM, Peter Zijlstra wrote:
- During the execution of a job, the task might invoke a blocking system
call,
and block... When it wakes up, it is still in the same
On Mon, 20 Jan 2014 12:46:06 +0100
Peter Zijlstra pet...@infradead.org wrote:
activates - released?
Since real-time papers from different rt-campus around the academia insist
on using *slightly* different terminology, perhaps add a short dictionary
for some of the more common terms?
On Tue, 21 Jan 2014 14:55:59 +0100
Peter Zijlstra pet...@infradead.org wrote:
I would strongly urge you not to use that as an example, because its
dead wrong design. An RT thread (be it RR,FIFO or DL) should _NEVER_ do
blocking IO.
Well, but it does happen in reality :)
Yeah, I know,
Hi all,
On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic fashion. The expected (maximum)
+ duration of such computation is called the task's runtime; the time interval
+
On Mon, Jan 20, 2014 at 01:15:51PM +0100, Juri Lelli wrote:
> On 01/20/2014 12:24 PM, Henrik Austad wrote:
> > On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
> >> From: Dario Faggioli
> >>
> >> Add in Documentation/scheduler/ some hints about the design
> >> choices, the usage and
Hi Juri,
On 01/20/2014 11:40 AM, Juri Lelli wrote:
From: Dario Faggioli
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
[...]
+ References:
+ 1 - C. L. Liu
On 01/20/2014 12:24 PM, Henrik Austad wrote:
> On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
>> From: Dario Faggioli
>>
>> Add in Documentation/scheduler/ some hints about the design
>> choices, the usage and the future possible developments of the
>> sched_dl scheduling class and
On Mon, Jan 20, 2014 at 12:24:42PM +0100, Henrik Austad wrote:
> > +2. Task scheduling
> > +==
> > +
> > + The typical -deadline task is composed of a computation phase (instance)
> > + which is activated on a periodic or sporadic fashion. The expected
> > (maximum)
> > + duration
On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add in Documentation/scheduler/ some hints about the design
> choices, the usage and the future possible developments of the
> sched_dl scheduling class and of the SCHED_DEADLINE policy.
>
> Cc:
On 01/20/2014 12:24 PM, Henrik Austad wrote:
On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class
Hi Juri,
On 01/20/2014 11:40 AM, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
[...]
+ References:
On Mon, Jan 20, 2014 at 01:15:51PM +0100, Juri Lelli wrote:
On 01/20/2014 12:24 PM, Henrik Austad wrote:
On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and
Hi all,
On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic fashion. The expected (maximum)
+ duration of such computation is called the task's runtime; the time interval
+
On Mon, Jan 20, 2014 at 11:40:40AM +0100, Juri Lelli wrote:
From: Dario Faggioli raist...@linux.it
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
Cc:
On Mon, Jan 20, 2014 at 12:24:42PM +0100, Henrik Austad wrote:
+2. Task scheduling
+==
+
+ The typical -deadline task is composed of a computation phase (instance)
+ which is activated on a periodic or sporadic fashion. The expected
(maximum)
+ duration of such
62 matches
Mail list logo
