Lines Matching refs:that

26  system behavior. As for -rt (group) scheduling, it is assumed that root users
36  that makes it possible to isolate the behavior of tasks between each other.
50  earliest scheduling deadline is selected for execution). Notice that the
56  that each task runs for at most its runtime every period, avoiding any
59  to be executed next. Thanks to this feature, tasks that do not strictly comply
125  scheduling discipline, even if it must be said that it is particularly
126  suited for periodic or sporadic real-time tasks that need guarantees on their
147  Note that total utilisation is defined as the sum of the utilisations
159  More precisely, it can be proven that using a global EDF scheduler the
175  (notice that this condition is only sufficient, and not necessary).
179  utilisations (it can be shown that task sets with utilisations slightly
181  However, as previously stated, enforcing that the total utilisation is smaller
182  than M is enough to guarantee that non real-time tasks are not starved and
183  that the tardiness of real-time tasks has an upper bound.
185  SCHED_DEADLINE can be used to schedule real-time tasks guaranteeing that
197  Notice that if runtime > deadline the admission control will surely reject
214  effective and useful (that is, to be able to provide "runtime" time units
221  correctly schedule a set of real-time tasks is that the total utilisation
222  is smaller than M. When talking about -deadline tasks, this requires that
224  than M. Notice that the ratio runtime/period is equivalent to the utilisation
227  The interface used to control the CPU bandwidth that can be allocated
232  Notice that per-group settings (controlled through cgroupfs) are still not
238  is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
240  desired bandwidth. In other words, this means that interface parameters are
243  parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
254  -deadline runtime is accounted against the -rt runtime. We realise that this
260  This means that, for a root_domain comprising M CPUs, -deadline tasks
273  Specifying a periodic/sporadic task that executes for a given amount of
274  runtime at each instance, and that is scheduled according to the urgency of
283   * the new scheduling related syscalls that manipulate it, i.e.,
291  950000. With rt_period equal to 1000000, by default, it means that -deadline
292  tasks can use at most 95%, multiplied by the number of CPUs that compose the
294  This means that non -deadline tasks will receive at least 5% of the CPU time,
295  and that -deadline tasks will receive their runtime with a guaranteed
299  deterministically guarantee that -deadline tasks will receive their runtime
302  Finally, notice that in order not to jeopardize the admission control a
308  -deadline tasks cannot have an affinity mask smaller that the entire
348  the preliminary phases of the merge and we really seek feedback that would
354  The SCHED_DEADLINE policy can be easily tested using two applications that
377  More interestingly, configurations can be described with a json file that
382  The parameters that can be specified with the second method are a superset
396  of 10ms every 100ms (note that parameters are expressed in microseconds).
398  application, given that you know its pid: