Lines Matching refs:deadline

43  "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
45  these "runtime" microseconds are available within "deadline" microseconds
47  every time the task wakes up, the scheduler computes a "scheduling deadline"
50  earliest scheduling deadline is selected for execution). Notice that the
51  task actually receives "runtime" time units within "deadline" if a proper
58  algorithm selects the task with the earliest scheduling deadline as the one
67     "deadline", and "period" parameters;
69   - The state of the task is described by a "scheduling deadline", and
77         scheduling deadline - current time           period
79     then, if the scheduling deadline is smaller than the current time, or
80     this condition is verified, the scheduling deadline and the
83          scheduling deadline = current time + deadline
86     otherwise, the scheduling deadline and the remaining runtime are
99     and cannot be scheduled until its scheduling deadline. The "replenishment
101     value of the scheduling deadline;
104     throttled task, the scheduling deadline and the remaining runtime are
107          scheduling deadline = scheduling deadline + period
116  * This section contains a (not-thorough) summary on classical deadline
134  time c_j needed to finish the job, and a job absolute deadline d_j, which
139  d_j = r_j + D, where D is the task's relative deadline.
158  between the finishing time of a job and its absolute deadline).
190   - deadline = D
197  Notice that if runtime > deadline the admission control will surely reject
213  As previously mentioned, in order for -deadline scheduling to be
215  within "deadline"), it is important to have some method to keep the allocation
218  no guarantee can be given on the actual scheduling of the -deadline tasks.
222  is smaller than M. When talking about -deadline tasks, this requires that
228  to -deadline tasks is similar to the one already used for -rt
233  defined for -deadline tasks, because more discussion is needed in order to
237  A main difference between deadline bandwidth management and RT-throttling
238  is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
245  interface we can put a cap on total utilization of -deadline tasks (i.e.,
253  For now the -rt knobs are used for -deadline admission control and the
254  -deadline runtime is accounted against the -rt runtime. We realise that this
257  run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
260  This means that, for a root_domain comprising M CPUs, -deadline tasks
291  950000. With rt_period equal to 1000000, by default, it means that -deadline
294  This means that non -deadline tasks will receive at least 5% of the CPU time,
295  and that -deadline tasks will receive their runtime with a guaranteed
296  worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
299  deterministically guarantee that -deadline tasks will receive their runtime
303  -deadline task cannot fork.
308  -deadline tasks cannot have an affinity mask smaller that the entire
315  An example of a simple configuration (pin a -deadline task to CPU0)
316  follows (rt-app is used to create a -deadline task).
337   - refinements to deadline inheritance, especially regarding the possibility
361  parameters (e.g., niceness, priority, runtime/deadline/period). rt-app
483 	printf("deadline thread started [%ld]\n", gettid());
506 	printf("deadline thread dies [%ld]\n", gettid());