Documentation/scheduler/sched-deadline.rst

53  "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
55  these "runtime" microseconds are available within "deadline" microseconds
57  every time the task wakes up, the scheduler computes a "scheduling deadline"
60  earliest scheduling deadline is selected for execution). Notice that the
61  task actually receives "runtime" time units within "deadline" if a proper
68  algorithm selects the task with the earliest scheduling deadline as the one
77     "deadline", and "period" parameters;
79   - The state of the task is described by a "scheduling deadline", and
87         scheduling deadline - current time           period
89     then, if the scheduling deadline is smaller than the current time, or
90     this condition is verified, the scheduling deadline and the
93          scheduling deadline = current time + deadline
96     otherwise, the scheduling deadline and the remaining runtime are
109     and cannot be scheduled until its scheduling deadline. The "replenishment
111     value of the scheduling deadline;
114     throttled task, the scheduling deadline and the remaining runtime are
117          scheduling deadline = scheduling deadline + period
128  Bandwidth reclaiming for deadline tasks is based on the GRUB (Greedy
174              deadline - ---------------------
224  Let's now see a trivial example of two deadline tasks with runtime equal
296  setting a fixed CPU frequency results in a lower amount of deadline misses.
308    This section contains a (not-thorough) summary on classical deadline
330  time c_j needed to finish the job, and a job absolute deadline d_j, which
335  d_j = r_j + D, where D is the task's relative deadline.
358  between the finishing time of a job and its absolute deadline).
388  EDF is clearly able to schedule the two tasks without missing any deadline
390  to respect its deadline; Task_2 is scheduled immediately after Task_1, hence
423  CPUs, with the first task Task_1=(P,P,P) having period, relative deadline
429  smaller than the absolute deadline of Task_1, which is t + P). As a
431  time t + e + P, after its absolute deadline. The total utilization of the
453  guarantee that global EDF schedules the tasks without missing any deadline
468  deadline and period) and the real-time task parameters (WCET, D, P)
479   - deadline = D
486  Notice that if runtime > deadline the admission control will surely reject
551  As previously mentioned, in order for -deadline scheduling to be
553  within "deadline"), it is important to have some method to keep the allocation
556  no guarantee can be given on the actual scheduling of the -deadline tasks.
560  is smaller than M. When talking about -deadline tasks, this requires that
566  to -deadline tasks is similar to the one already used for -rt
571  defined for -deadline tasks, because more discussion is needed in order to
575  A main difference between deadline bandwidth management and RT-throttling
576  is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
583  interface we can put a cap on total utilization of -deadline tasks (i.e.,
591  For now the -rt knobs are used for -deadline admission control and the
592  -deadline runtime is accounted against the -rt runtime. We realize that this
595  run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
598  This means that, for a root_domain comprising M CPUs, -deadline tasks
626  For debugging purposes, the leftover runtime and absolute deadline of a
628  dl.runtime and dl.deadline, both values in ns). A programmatic way to
636  950000. With rt_period equal to 1000000, by default, it means that -deadline
639  This means that non -deadline tasks will receive at least 5% of the CPU time,
640  and that -deadline tasks will receive their runtime with a guaranteed
641  worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
644  deterministically guarantee that -deadline tasks will receive their runtime
648  -deadline task cannot fork.
670  -deadline tasks cannot have an affinity mask smaller that the entire
677  An example of a simple configuration (pin a -deadline task to CPU0)
678  follows (rt-app is used to create a -deadline task)::
699   - programmatic way to retrieve current runtime and absolute deadline
700   - refinements to deadline inheritance, especially regarding the possibility
724  parameters (e.g., niceness, priority, runtime/deadline/period). rt-app
846 	printf("deadline thread started [%ld]\n", gettid());
869 	printf("deadline thread dies [%ld]\n", gettid());