Lines Matching refs:runtime
46 SCHED_DEADLINE uses three parameters, named "runtime", "period", and
48 "runtime" microseconds of execution time every "period" microseconds, and
49 these "runtime" microseconds are available within "deadline" microseconds
55 task actually receives "runtime" time units within "deadline" if a proper
60 that each task runs for at most its runtime every period, avoiding any
70 - Each SCHED_DEADLINE task is characterized by the "runtime",
74 a "remaining runtime". These two parameters are initially set to 0;
79 remaining runtime runtime
85 remaining runtime are re-initialized as
88 remaining runtime = runtime
90 otherwise, the scheduling deadline and the remaining runtime are
94 remaining runtime is decreased as
96 remaining runtime = remaining runtime - t
98 (technically, the runtime is decreased at every tick, or when the
101 - When the remaining runtime becomes less or equal than 0, the task is
108 throttled task, the scheduling deadline and the remaining runtime are
112 remaining runtime = remaining runtime + runtime
269 SCHED_DEADLINE scheduling parameters described in Section 2 (runtime,
280 - runtime >= WCET
284 IOW, if runtime >= WCET and if period is <= P, then the scheduling deadlines
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
347 the sum of the ratio between runtime and period for all tasks is smaller
348 than M. Notice that the ratio runtime/period is equivalent to the utilization
378 -deadline runtime is accounted against the -rt runtime. We realize that this
398 runtime at each instance, and that is scheduled according to the urgency of
419 and that -deadline tasks will receive their runtime with a guaranteed
423 deterministically guarantee that -deadline tasks will receive their runtime
485 parameters (e.g., niceness, priority, runtime/deadline/period). rt-app