Lines Matching refs:that
30 system behavior. As for -rt (group) scheduling, it is assumed that root users
40 that makes it possible to isolate the behavior of tasks between each other.
54 earliest scheduling deadline is selected for execution). Notice that the
60 that each task runs for at most its runtime every period, avoiding any
63 to be executed next. Thanks to this feature, tasks that do not strictly comply
129 scheduling discipline, even if it must be said that it is particularly
130 suited for periodic or sporadic real-time tasks that need guarantees on their
157 Note that total utilization is defined as the sum of the utilizations
169 More precisely, it can be proven that using a global EDF scheduler the
190 It is important to notice that this condition is only sufficient, and not
191 necessary: there are task sets that are schedulable, but do not respect the
200 D_i != P_i (checking a condition that is both sufficient and necessary),
205 such a time with the interval size t. If h(t) is smaller than t (that is,
210 proven[4,5,6] that it is sufficient to perform the test for values of t
222 utilizations or densities: it can be shown that even if D_i = P_i task
248 where U_max = max{WCET_i / P_i}[10]. Notice that for U_max = 1,
254 As seen, enforcing that the total utilization is smaller than M does not
255 guarantee that global EDF schedules the tasks without missing any deadline
257 a total utilization smaller than M is enough to guarantee that non real-time
258 tasks are not starved and that the tardiness of real-time tasks has an upper
261 but the theoretical result that is important for SCHED_DEADLINE is that if
271 described in this section. Note that the tasks' temporal constraints are
275 If an admission test is used to guarantee that the scheduling deadlines
277 guaranteeing that all the jobs' deadlines of a task are respected.
288 Notice that if runtime > deadline the admission control will surely reject
338 effective and useful (that is, to be able to provide "runtime" time units
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
348 than M. Notice that the ratio runtime/period is equivalent to the utilization
351 The interface used to control the CPU bandwidth that can be allocated
356 Notice that per-group settings (controlled through cgroupfs) are still not
362 is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
364 desired bandwidth. In other words, this means that interface parameters are
367 parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
378 -deadline runtime is accounted against the -rt runtime. We realize that this
384 This means that, for a root_domain comprising M CPUs, -deadline tasks
397 Specifying a periodic/sporadic task that executes for a given amount of
398 runtime at each instance, and that is scheduled according to the urgency of
407 * the new scheduling related syscalls that manipulate it, i.e.,
415 950000. With rt_period equal to 1000000, by default, it means that -deadline
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
426 Finally, notice that in order not to jeopardize the admission control a
432 -deadline tasks cannot have an affinity mask smaller that the entire
472 the preliminary phases of the merge and we really seek feedback that would
478 The SCHED_DEADLINE policy can be easily tested using two applications that
501 More interestingly, configurations can be described with a json file that
506 The parameters that can be specified with the second method are a superset
520 of 10ms every 100ms (note that parameters are expressed in microseconds).
522 application, given that you know its pid: