Messages in this thread | | | Date | Wed, 10 Nov 2010 17:00:04 +0100 | From | Dhaval Giani <> | Subject | Re: [RFC][PATCH 02/22] sched: add extended scheduling interface |
| |
> +/* > + * 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
| |