On Fri, 2010-10-29 at 08:27 +0200, Raistlin wrote:
> +/*
> + * Extended scheduling parameters data structure.
> + *
> + * This is needed because the original struct sched_param can not be
> + * altered without introducing ABI issues with legacy applications
> + * (e.g., in sched_getparam()).
> + *
> + * However, the possibility of specifying more than just a priority for
> + * the tasks may be useful for a wide variety of application fields, e.g.,
> + * multimedia, streaming, automation and control, and many others.
> + *
> + * This variant (sched_param_ex) is meant at describing a so-called
> + * sporadic time-constrained task. In such model a task is specified by:
> + * - the activation period or minimum instance inter-arrival time;
> + * - the maximum (or average, depending on the actual scheduling
> + * discipline) computation time of all instances, a.k.a. runtime;
> + * - the deadline (relative to the actual activation time) of each
> + * instance.
> + * Very briefly, a periodic (sporadic) task asks for the execution of
> + * some specific computation --which is typically called an instance--
> + * (at most) every period. Moreover, each instance typically lasts no more
> + * than the runtime and must be completed by time instant t equal to
> + * the instance activation time + the deadline.
> + *
> + * This is reflected by the actual fields of the sched_param_ex structure:
> + *
> + * @sched_priority task's priority (might still be useful)
> + * @sched_deadline representative of the task's deadline
> + * @sched_runtime representative of the task's runtime
> + * @sched_period representative of the task's period
> + * @sched_flags for customizing the scheduler behaviour
> + *
> + * There are other fields, which may be useful for implementing (in
> + * user-space) advanced scheduling behaviours, e.g., feedback scheduling:
> + *
> + * @curr_runtime task's currently available runtime
> + * @used_runtime task's totally used runtime
> + * @curr_deadline task's current absolute deadline
> + *
> + * Given this task model, there are a multiplicity of scheduling algorithms
> + * and policies, that can be used to ensure all the tasks will make their
> + * timing constraints.
> + */
A while ago I implemented an EDF scheduler for a client (before working
with Red Hat), and one thing they asked about was having a "soft group",
which was basically: This group is guaranteed X runtime in Y period, but
if the system is idle, let the group run, even if it has exhausted its X
runtime.
Is this supported?
-- Steve
On Fri, 2010-11-12 at 11:38 -0500, Steven Rostedt wrote:
> A while ago I implemented an EDF scheduler for a client (before working
> with Red Hat), and one thing they asked about was having a "soft group",
> which was basically: This group is guaranteed X runtime in Y period, but
> if the system is idle, let the group run, even if it has exhausted its X
> runtime.
>
> Is this supported?
No, some of the bits in 18/22 come near, but I'd prefer not to add such
things until we've got a convincing use-case.
On Fri, 2010-11-12 at 17:43 +0100, Peter Zijlstra wrote:
> On Fri, 2010-11-12 at 11:38 -0500, Steven Rostedt wrote:
> > A while ago I implemented an EDF scheduler for a client (before working
> > with Red Hat), and one thing they asked about was having a "soft group",
> > which was basically: This group is guaranteed X runtime in Y period, but
> > if the system is idle, let the group run, even if it has exhausted its X
> > runtime.
> >
> > Is this supported?
>
> No, some of the bits in 18/22 come near, but I'd prefer not to add such
> things until we've got a convincing use-case.
I'm fine with that, but I would like to know if the ABI would be able to
add such an extension in the future if we find a convincing use-case.
-- Steve
Il 12/11/2010 17:38, Steven Rostedt ha scritto:
> A while ago I implemented an EDF scheduler for a client (before working
> with Red Hat), and one thing they asked about was having a "soft group",
> which was basically: This group is guaranteed X runtime in Y period, but
> if the system is idle, let the group run, even if it has exhausted its X
> runtime.
>
> Is this supported?
Actually, I know that Dario has an implementation of exactly this
feature (and it used to be implemented in our previous scheduler as
well, i.e., the old AQuoSA stuff):
a per-task flag, when enabled, allows to put temporarily the task into
SCHED_OTHER when its budget is exhausted. Therefore, it will be allowed
to run for more than its budget but without breaking the temporal
isolation with the other SCHED_DEADLINE tasks. Furthermore, it won't
starve other SCHED_OTHER tasks, as it will compete with them for the CPU
during the budget-exhausted time windows.
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
On Fri, 2010-11-12 at 11:52 -0500, Steven Rostedt wrote:
> > No, some of the bits in 18/22 come near, but I'd prefer not to add such
> > things until we've got a convincing use-case.
>
> I'm fine with that, but I would like to know if the ABI would be able to
> add such an extension in the future if we find a convincing use-case.
>
Scared about ABIs' stability eh? :-PP
BTW, in this case everything should be fine, since the very exact
behaviour you described was triggered by a (couple of) flag(s), which
can be added and dealt with during sched_setscheduler2() at any time.
As Peter was saying, see patch 18 for details.
Thanks,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
http://blog.linux.it/raistlin / [email protected] /
[email protected]
On Fri, 2010-11-12 at 18:42 +0100, Tommaso Cucinotta wrote:
> Il 12/11/2010 17:38, Steven Rostedt ha scritto:
> > A while ago I implemented an EDF scheduler for a client (before working
> > with Red Hat), and one thing they asked about was having a "soft group",
> > which was basically: This group is guaranteed X runtime in Y period, but
> > if the system is idle, let the group run, even if it has exhausted its X
> > runtime.
> >
> > Is this supported?
> Actually, I know that Dario has an implementation of exactly this
> feature (and it used to be implemented in our previous scheduler as
> well, i.e., the old AQuoSA stuff):
> a per-task flag, when enabled, allows to put temporarily the task into
> SCHED_OTHER when its budget is exhausted. Therefore, it will be allowed
> to run for more than its budget but without breaking the temporal
> isolation with the other SCHED_DEADLINE tasks. Furthermore, it won't
> starve other SCHED_OTHER tasks, as it will compete with them for the CPU
> during the budget-exhausted time windows.
Good to know, thanks!
-- Steve
On Fri, 2010-11-12 at 20:19 +0100, Raistlin wrote:
> On Fri, 2010-11-12 at 11:52 -0500, Steven Rostedt wrote:
> > > No, some of the bits in 18/22 come near, but I'd prefer not to add such
> > > things until we've got a convincing use-case.
> >
> > I'm fine with that, but I would like to know if the ABI would be able to
> > add such an extension in the future if we find a convincing use-case.
> >
> Scared about ABIs' stability eh? :-PP
Nah, why should I be? ;-)
>
> BTW, in this case everything should be fine, since the very exact
> behaviour you described was triggered by a (couple of) flag(s), which
> can be added and dealt with during sched_setscheduler2() at any time.
Yep.
>
> As Peter was saying, see patch 18 for details.
I'm slowly getting there ;-)
-- Steve
On Fri, 2010-11-12 at 11:38 -0500, Steven Rostedt wrote:
> A while ago I implemented an EDF scheduler for a client (before working
> with Red Hat), and one thing they asked about was having a "soft group",
> which was basically: This group is guaranteed X runtime in Y period, but
> if the system is idle, let the group run, even if it has exhausted its X
> runtime.
>
Sounds reasonable...
> Is this supported?
>
Yep, as both Tommaso and Peter were saying, patch 18 gives you exactly
that. In some more details, after X is over, you can chose (just by
setting a flag in sched_param2 and calling setscheduler2()) if you want
to keep running as a -deadline task (but without hurting other -deadline
tasks), or if you want to still be able to compete for CPU, but as a -rt
or -fair task.
However, we're delaying this for now. It won't be hard to add it back if
we change our mind. :-)
Thanks,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
http://blog.linux.it/raistlin / [email protected] /
[email protected]