Lines Matching refs:deadline
47 "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
49 these "runtime" microseconds are available within "deadline" microseconds
51 every time the task wakes up, the scheduler computes a "scheduling deadline"
54 earliest scheduling deadline is selected for execution). Notice that the
55 task actually receives "runtime" time units within "deadline" if a proper
62 algorithm selects the task with the earliest scheduling deadline as the one
71 "deadline", and "period" parameters;
73 - The state of the task is described by a "scheduling deadline", and
81 scheduling deadline - current time period
83 then, if the scheduling deadline is smaller than the current time, or
84 this condition is verified, the scheduling deadline and the
87 scheduling deadline = current time + deadline
90 otherwise, the scheduling deadline and the remaining runtime are
103 and cannot be scheduled until its scheduling deadline. The "replenishment
105 value of the scheduling deadline;
108 throttled task, the scheduling deadline and the remaining runtime are
111 scheduling deadline = scheduling deadline + period
120 * This section contains a (not-thorough) summary on classical deadline
141 time c_j needed to finish the job, and a job absolute deadline d_j, which
146 d_j = r_j + D, where D is the task's relative deadline.
168 between the finishing time of a job and its absolute deadline).
194 EDF is clearly able to schedule the two tasks without missing any deadline
196 to respect its deadline; Task_2 is scheduled immediately after Task_1, hence
227 CPUs, with the first task Task_1=(P,P,P) having period, relative deadline
233 smaller than the absolute deadline of Task_1, which is t + P). As a
235 time t + e + P, after its absolute deadline. The total utilization of the
255 guarantee that global EDF schedules the tasks without missing any deadline
270 deadline and period) and the real-time task parameters (WCET, D, P)
281 - deadline = D
288 Notice that if runtime > deadline the admission control will surely reject
337 As previously mentioned, in order for -deadline scheduling to be
339 within "deadline"), it is important to have some method to keep the allocation
342 no guarantee can be given on the actual scheduling of the -deadline tasks.
346 is smaller than M. When talking about -deadline tasks, this requires that
352 to -deadline tasks is similar to the one already used for -rt
357 defined for -deadline tasks, because more discussion is needed in order to
361 A main difference between deadline bandwidth management and RT-throttling
362 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
369 interface we can put a cap on total utilization of -deadline tasks (i.e.,
377 For now the -rt knobs are used for -deadline admission control and the
378 -deadline runtime is accounted against the -rt runtime. We realize that this
381 run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
384 This means that, for a root_domain comprising M CPUs, -deadline tasks
415 950000. With rt_period equal to 1000000, by default, it means that -deadline
418 This means that non -deadline tasks will receive at least 5% of the CPU time,
419 and that -deadline tasks will receive their runtime with a guaranteed
420 worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
423 deterministically guarantee that -deadline tasks will receive their runtime
427 -deadline task cannot fork.
432 -deadline tasks cannot have an affinity mask smaller that the entire
439 An example of a simple configuration (pin a -deadline task to CPU0)
440 follows (rt-app is used to create a -deadline task).
461 - refinements to deadline inheritance, especially regarding the possibility
485 parameters (e.g., niceness, priority, runtime/deadline/period). rt-app
607 printf("deadline thread started [%ld]\n", gettid());
630 printf("deadline thread dies [%ld]\n", gettid());