On Fri, 2010-10-29 at 08:31 +0200, Raistlin wrote:
>
> There sometimes is the need of executing a task as if it would
> have the maximum possible priority in the entire system, i.e.,
> whenever it gets ready it must run! This is for example the case
> for some maintainance kernel thread like migration and (sometimes)
> watchdog or ksoftirq.
>
> Since SCHED_DEADLINE is now the highest priority scheduling class
> these tasks have to be handled therein, but it is not obvious how
> to choose a runtime and a deadline that guarantee what explained
> above. Therefore, we need a mean of recognizing system tasks inside
> the -deadline class and always run them as soon as possible, without
> any kind of runtime and bandwidth limitation.
>
> This patch:
> - adds the SF_HEAD flag, which identify a special task that need
> absolute prioritization among any other task;
> - ensures that special tasks always preempt everyone else (and,
> obviously, are not preempted by non special tasks);
> - disables runtime and bandwidth checking for such tasks, hoping
> that the interference they cause is small enough.
>
Yet in the previous patch you had this hunk:
> +++ b/kernel/sched_stoptask.c
> @@ -81,7 +81,7 @@ get_rr_interval_stop(struct rq *rq, struct
> task_struct *task)
> * Simple, special scheduling class for the per-CPU stop tasks:
> */
> static const struct sched_class stop_sched_class = {
> - .next = &rt_sched_class,
> + .next = &dl_sched_class,
>
> .enqueue_task = enqueue_task_stop,
> .dequeue_task = dequeue_task_stop,
On Thu, 2010-11-11 at 15:31 +0100, Peter Zijlstra wrote:
> > Since SCHED_DEADLINE is now the highest priority scheduling class
> > these tasks have to be handled therein, but it is not obvious how
> > to choose a runtime and a deadline that guarantee what explained
> > above. Therefore, we need a mean of recognizing system tasks inside
> > the -deadline class and always run them as soon as possible, without
> > any kind of runtime and bandwidth limitation.
>
> Yet in the previous patch you had this hunk:
>
> > +++ b/kernel/sched_stoptask.c
> > @@ -81,7 +81,7 @@ get_rr_interval_stop(struct rq *rq, struct
> > task_struct *task)
> > * Simple, special scheduling class for the per-CPU stop tasks:
> > */
> > static const struct sched_class stop_sched_class = {
> > - .next = &rt_sched_class,
> > + .next = &dl_sched_class,
> >
> > .enqueue_task = enqueue_task_stop,
> > .dequeue_task = dequeue_task_stop,
>
Yep. And (as said on IRC) this needs serious cleanup, in favour of
stop_task!
I'll completely drop patch 06 for next releases.
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]