> +/*
> + * 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.
> + */
> +struct sched_param_ex {
> + int sched_priority;
> + struct timespec sched_runtime;
> + struct timespec sched_deadline;
> + struct timespec sched_period;
> + unsigned int sched_flags;
> +
> + struct timespec curr_runtime;
> + struct timespec used_runtime;
> + struct timespec curr_deadline;
> +};
> +
So, how extensible is this. What about when real time theory develops a
new algorithm which actually works practically, but needs additional
parameters? :-). (I am guessing that this interface should handle most
of the algorithms used these days). Any ideas?
Thanks,
Dhaval
On Wed, Nov 10, 2010 at 5:00 PM, Dhaval Giani <[email protected]> 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.
>> + */
>> +struct sched_param_ex {
>> + ? ? int sched_priority;
>> + ? ? struct timespec sched_runtime;
>> + ? ? struct timespec sched_deadline;
>> + ? ? struct timespec sched_period;
>> + ? ? unsigned int sched_flags;
>> +
>> + ? ? struct timespec curr_runtime;
>> + ? ? struct timespec used_runtime;
>> + ? ? struct timespec curr_deadline;
Can we expose soem of these details via schedstats as opposed to a syscall?
Dhaval
Dhaval Giani ha scritto:
>> +/*
>> + * 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.
>> + */
>> +struct sched_param_ex {
>> + int sched_priority;
>> + struct timespec sched_runtime;
>> + struct timespec sched_deadline;
>> + struct timespec sched_period;
>> + unsigned int sched_flags;
>> +
>> + struct timespec curr_runtime;
>> + struct timespec used_runtime;
>> + struct timespec curr_deadline;
>> +};
>> +
>
> So, how extensible is this. What about when real time theory develops a
> new algorithm which actually works practically, but needs additional
> parameters? :-). (I am guessing that this interface should handle most
> of the algorithms used these days). Any ideas?
AFAIK, these parameters already address most real-time algorithms.
It could happen that in the future a new algorithm will need some
further parameter (like jitter). However, IMHO, this is too unlikely
to justify the addition of some padding in this data structure.
Best regards,
Claudio
On Wed, 2010-11-10 at 17:12 +0100, Dhaval Giani wrote:
> >> + * @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.
> >> + */
> >> +struct sched_param_ex {
> >> + int sched_priority;
> >> + struct timespec sched_runtime;
> >> + struct timespec sched_deadline;
> >> + struct timespec sched_period;
> >> + unsigned int sched_flags;
> >> +
> >> + struct timespec curr_runtime;
> >> + struct timespec used_runtime;
> >> + struct timespec curr_deadline;
>
> Can we expose soem of these details via schedstats as opposed to a syscall?
>
Actually, good point... schedstats seems very reasonable to me... What
do the others think?
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]