Messages in this thread | | | Date | Wed, 10 Nov 2010 17:12:56 +0100 | Subject | Re: [RFC][PATCH 02/22] sched: add extended scheduling interface | From | Dhaval Giani <> |
| |
On Wed, Nov 10, 2010 at 5:00 PM, Dhaval Giani <dhaval@retis.sssup.it> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |