lkml.org 
[lkml]   [2010]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 06/22] sched: SCHED_DEADLINE handles spacial kthreads
From
Date
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,



\
 
 \ /
  Last update: 2010-11-11 15:33    [W:0.448 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site