Lines Matching refs:tasks
43 that makes it possible to isolate the behavior of tasks between each other.
53 "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
65 Summing up, the CBS[2,3] algorithm assigns scheduling deadlines to tasks so
67 interference between different tasks (bandwidth isolation), while the EDF[1]
69 to be executed next. Thanks to this feature, tasks that do not strictly comply
74 tasks in the following way:
128 Bandwidth reclaiming for deadline tasks is based on the GRUB (Greedy
132 The following diagram illustrates the state names for tasks handled by GRUB::
201 tasks in active state (i.e., ActiveContending or ActiveNonContending);
203 - Total bandwidth (this_bw): this is the sum of all tasks "belonging" to the
204 runqueue, including the tasks in Inactive state.
207 The algorithm reclaims the bandwidth of the tasks in Inactive state.
224 Let's now see a trivial example of two deadline tasks with runtime equal
259 Both tasks are ready for execution and therefore in ActiveContending state.
261 Since there are no inactive tasks, its runtime is decreased as dq = -1 dt.
269 there are no inactive tasks.
319 suited for periodic or sporadic real-time tasks that need guarantees on their
348 WCET_i/P_i over all the real-time tasks in the system. When considering
349 multiple real-time tasks, the parameters of the i-th task are indicated
352 non- real-time tasks by real-time tasks.
354 tasks will not be starved and the system might be able to respect all the
374 If D_i = P_i for all tasks, then EDF is able to respect all the deadlines
375 of all the tasks executing on a CPU if and only if the total utilization
376 of the tasks running on such a CPU is smaller or equal than 1.
379 of all the tasks running on a CPU if the sum of the densities of the tasks
388 EDF is clearly able to schedule the two tasks without missing any deadline
395 Of course it is possible to test the exact schedulability of tasks with
399 computing the total amount of CPU time h(t) needed by all the tasks to
402 the amount of time needed by the tasks in a time interval of size t is
404 EDF is able to schedule the tasks respecting all of their deadlines. Since
411 4 Linux uses an admission test based on the tasks' utilizations.
422 Consider a set {Task_1,...Task_{M+1}} of M+1 tasks on a system with M
424 and WCET equal to P. The remaining M tasks Task_i=(e,P-1,P-1) have an
426 period smaller than the one of the first task. Hence, if all the tasks
427 activate at the same time t, global EDF schedules these M tasks first
440 between total utilization (or density) and a fixed constant. If all tasks
453 guarantee that global EDF schedules the tasks without missing any deadline
456 tasks are not starved and that the tardiness of real-time tasks has an upper
458 experienced by real-time tasks have been developed in various papers[13,14],
461 the tasks are limited.
469 described in this section. Note that the tasks' temporal constraints are
471 SCHED_DEADLINE schedules the tasks according to scheduling deadlines (see
474 are respected, then SCHED_DEADLINE can be used to schedule real-time tasks
506 Concerning the Preemptive Scheduling of Periodic Real-Time tasks on
554 of the available fractions of CPU time to the various tasks under control.
556 no guarantee can be given on the actual scheduling of the -deadline tasks.
559 correctly schedule a set of real-time tasks is that the total utilization
560 is smaller than M. When talking about -deadline tasks, this requires that
561 the sum of the ratio between runtime and period for all tasks is smaller
566 to -deadline tasks is similar to the one already used for -rt
567 tasks with real-time group scheduling (a.k.a. RT-throttling - see
571 defined for -deadline tasks, because more discussion is needed in order to
576 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
580 sched_setattr()). Scheduling is then performed considering actual tasks'
581 parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
583 interface we can put a cap on total utilization of -deadline tasks (i.e.,
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
637 tasks can use at most 95%, multiplied by the number of CPUs that compose the
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
644 deterministically guarantee that -deadline tasks will receive their runtime
664 SCHED_DEADLINE tasks.
670 -deadline tasks cannot have an affinity mask smaller that the entire
690 echo $$ > cpu0/tasks
701 of retaining bandwidth isolation among non-interacting tasks. This is