Lines Matching full:tasks
12 3. Scheduling Real-Time Tasks
22 5. Tasks CPU affinity
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
58 consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then
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 deadline tasks and is currently set to the RT capacity.
210 The algorithm reclaims the bandwidth of the tasks in Inactive state.
227 Let's now see a trivial example of two deadline tasks with runtime equal
262 Both tasks are ready for execution and therefore in ActiveContending state.
264 Since there are no inactive tasks, its runtime is decreased as dq = -1 dt.
272 there are no inactive tasks.
302 3. Scheduling Real-Time Tasks
322 suited for periodic or sporadic real-time tasks that need guarantees on their
351 WCET_i/P_i over all the real-time tasks in the system. When considering
352 multiple real-time tasks, the parameters of the i-th task are indicated
355 non- real-time tasks by real-time tasks.
357 tasks will not be starved and the system might be able to respect all the
377 If D_i = P_i for all tasks, then EDF is able to respect all the deadlines
378 of all the tasks executing on a CPU if and only if the total utilization
379 of the tasks running on such a CPU is smaller or equal than 1.
382 of all the tasks running on a CPU if the sum of the densities of the tasks
391 EDF is clearly able to schedule the two tasks without missing any deadline
398 Of course it is possible to test the exact schedulability of tasks with
402 computing the total amount of CPU time h(t) needed by all the tasks to
405 the amount of time needed by the tasks in a time interval of size t is
407 EDF is able to schedule the tasks respecting all of their deadlines. Since
414 4 Linux uses an admission test based on the tasks' utilizations.
425 Consider a set {Task_1,...Task_{M+1}} of M+1 tasks on a system with M
427 and WCET equal to P. The remaining M tasks Task_i=(e,P-1,P-1) have an
429 period smaller than the one of the first task. Hence, if all the tasks
430 activate at the same time t, global EDF schedules these M tasks first
443 between total utilization (or density) and a fixed constant. If all tasks
456 guarantee that global EDF schedules the tasks without missing any deadline
459 tasks are not starved and that the tardiness of real-time tasks has an upper
461 experienced by real-time tasks have been developed in various papers[13,14],
464 the tasks are limited.
472 described in this section. Note that the tasks' temporal constraints are
474 SCHED_DEADLINE schedules the tasks according to scheduling deadlines (see
477 are respected, then SCHED_DEADLINE can be used to schedule real-time tasks
503 Periodic, Real-Time Tasks. Information Processing Letters, vol. 11,
506 Hard-Real-Time Sporadic Tasks on One Processor. Proceedings of the
509 Concerning the Preemptive Scheduling of Periodic Real-Time tasks on
529 Real-Time Tasks Scheduled by EDF on Multiprocessors. Proceedings of
557 of the available fractions of CPU time to the various tasks under control.
559 no guarantee can be given on the actual scheduling of the -deadline tasks.
562 correctly schedule a set of real-time tasks is that the total utilization
563 is smaller than M. When talking about -deadline tasks, this requires that
564 the sum of the ratio between runtime and period for all tasks is smaller
569 to -deadline tasks is similar to the one already used for -rt
570 tasks with real-time group scheduling (a.k.a. RT-throttling - see
574 defined for -deadline tasks, because more discussion is needed in order to
579 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
583 sched_setattr()). Scheduling is then performed considering actual tasks'
584 parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
586 interface we can put a cap on total utilization of -deadline tasks (i.e.,
598 run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
601 This means that, for a root_domain comprising M CPUs, -deadline tasks
640 tasks can use at most 95%, multiplied by the number of CPUs that compose the
642 This means that non -deadline tasks will receive at least 5% of the CPU time,
643 and that -deadline tasks will receive their runtime with a guaranteed
647 deterministically guarantee that -deadline tasks will receive their runtime
667 SCHED_DEADLINE tasks.
670 5. Tasks CPU affinity
673 -deadline tasks cannot have an affinity mask smaller that the entire
693 echo $$ > cpu0/tasks
704 of retaining bandwidth isolation among non-interacting tasks. This is