Lines Matching full:deadline
2 Deadline Task Scheduling
41 basically an implementation of the Earliest Deadline First (EDF) scheduling
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 - ---------------------
207 deadline tasks and is currently set to the RT capacity.
227 Let's now see a trivial example of two deadline tasks with runtime equal
299 setting a fixed CPU frequency results in a lower amount of deadline misses.
311 This section contains a (not-thorough) summary on classical deadline
333 time c_j needed to finish the job, and a job absolute deadline d_j, which
338 d_j = r_j + D, where D is the task's relative deadline.
361 between the finishing time of a job and its absolute deadline).
391 EDF is clearly able to schedule the two tasks without missing any deadline
393 to respect its deadline; Task_2 is scheduled immediately after Task_1, hence
426 CPUs, with the first task Task_1=(P,P,P) having period, relative deadline
432 smaller than the absolute deadline of Task_1, which is t + P). As a
434 time t + e + P, after its absolute deadline. The total utilization of the
456 guarantee that global EDF schedules the tasks without missing any deadline
471 deadline and period) and the real-time task parameters (WCET, D, P)
482 - deadline = D
489 Notice that if runtime > deadline the admission control will surely reject
514 8 - T. Baker. Multiprocessor EDF and Deadline Monotonic Schedulability
538 SCHED DEADLINE. In Proceedings of the Real-Time Linux Workshop (RTLWS),
543 18 - J. Lelli, C. Scordino, L. Abeni, D. Faggioli, Deadline scheduling in the
554 As previously mentioned, in order for -deadline scheduling to be
556 within "deadline"), it is important to have some method to keep the allocation
559 no guarantee can be given on the actual scheduling of the -deadline tasks.
563 is smaller than M. When talking about -deadline tasks, this requires that
569 to -deadline tasks is similar to the one already used for -rt
574 defined for -deadline tasks, because more discussion is needed in order to
578 A main difference between deadline bandwidth management and RT-throttling
579 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
586 interface we can put a cap on total utilization of -deadline tasks (i.e.,
594 For now the -rt knobs are used for -deadline admission control and with
595 CONFIG_RT_GROUP_SCHED the -deadline runtime is accounted against the (root)
599 later. The ideal situation (see 5.) is to run -rt tasks from a -deadline
602 This means that, for a root_domain comprising M CPUs, -deadline tasks
630 For debugging purposes, the leftover runtime and absolute deadline of a
632 dl.runtime and dl.deadline, both values in ns). A programmatic way to
640 950000. With rt_period equal to 1000000, by default, it means that -deadline
643 This means that non -deadline tasks will receive at least 5% of the CPU time,
644 and that -deadline tasks will receive their runtime with a guaranteed
645 worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
648 deterministically guarantee that -deadline tasks will receive their runtime
652 -deadline task cannot fork.
674 -deadline tasks cannot have an affinity mask smaller that the entire
681 An example of a simple configuration (pin a -deadline task to CPU0)
682 follows (rt-app is used to create a -deadline task)::
703 - programmatic way to retrieve current runtime and absolute deadline
704 - refinements to deadline inheritance, especially regarding the possibility
727 SCHED_{OTHER,FIFO,RR,DEADLINE} scheduling policies and their related
728 parameters (e.g., niceness, priority, runtime/deadline/period). rt-app
848 printf("deadline thread started [%ld]\n", gettid());
871 printf("deadline thread dies [%ld]\n", gettid());