Lines Matching refs:tasks
40 that makes it possible to isolate the behavior of tasks between each other.
47 "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
59 Summing up, the CBS[2,3] algorithm assigns scheduling deadlines to tasks so
61 interference between different tasks (bandwidth isolation), while the EDF[1]
63 to be executed next. Thanks to this feature, tasks that do not strictly comply
68 tasks in the following way:
130 suited for periodic or sporadic real-time tasks that need guarantees on their
158 WCET_i/P_i over all the real-time tasks in the system. When considering
159 multiple real-time tasks, the parameters of the i-th task are indicated
162 non- real-time tasks by real-time tasks.
164 tasks will not be starved and the system might be able to respect all the
182 If D_i = P_i for all tasks, then EDF is able to respect all the deadlines
183 of all the tasks executing on a CPU if and only if the total utilization
184 of the tasks running on such a CPU is smaller or equal than 1.
187 of all the tasks running on a CPU if the sum of the densities of the tasks
194 EDF is clearly able to schedule the two tasks without missing any deadline
199 Of course it is possible to test the exact schedulability of tasks with
203 computing the total amount of CPU time h(t) needed by all the tasks to
206 the amount of time needed by the tasks in a time interval of size t is
208 EDF is able to schedule the tasks respecting all of their deadlines. Since
215 4 Linux uses an admission test based on the tasks' utilizations.
226 Consider a set {Task_1,...Task_{M+1}} of M+1 tasks on a system with M
228 and WCET equal to P. The remaining M tasks Task_i=(e,P-1,P-1) have an
230 period smaller than the one of the first task. Hence, if all the tasks
231 activate at the same time t, global EDF schedules these M tasks first
244 between total utilization (or density) and a fixed constant. If all tasks
255 guarantee that global EDF schedules the tasks without missing any deadline
258 tasks are not starved and that the tardiness of real-time tasks has an upper
260 experienced by real-time tasks have been developed in various papers[13,14],
263 the tasks are limited.
271 described in this section. Note that the tasks' temporal constraints are
273 SCHED_DEADLINE schedules the tasks according to scheduling deadlines (see
276 are respected, then SCHED_DEADLINE can be used to schedule real-time tasks
307 Concerning the Preemptive Scheduling of Periodic Real-Time tasks on
340 of the available fractions of CPU time to the various tasks under control.
342 no guarantee can be given on the actual scheduling of the -deadline tasks.
345 correctly schedule a set of real-time tasks is that the total utilization
346 is smaller than M. When talking about -deadline tasks, this requires that
347 the sum of the ratio between runtime and period for all tasks is smaller
352 to -deadline tasks is similar to the one already used for -rt
353 tasks with real-time group scheduling (a.k.a. RT-throttling - see
357 defined for -deadline tasks, because more discussion is needed in order to
362 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
366 sched_setattr()). Scheduling is then performed considering actual tasks'
367 parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
369 interface we can put a cap on total utilization of -deadline tasks (i.e.,
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
416 tasks can use at most 95%, multiplied by the number of CPUs that compose the
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
423 deterministically guarantee that -deadline tasks will receive their runtime
432 -deadline tasks cannot have an affinity mask smaller that the entire
452 echo $$ > cpu0/tasks
462 of retaining bandwidth isolation among non-interacting tasks. This is