mirror of https://github.com/mkerrisk/man-pages
sched.7: Add lots of details on SCHED_DEADLINE
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
0756f58ff1
commit
9cc1fa25fc
163
man7/sched.7
163
man7/sched.7
|
@ -194,22 +194,35 @@ retrieved using
|
||||||
.\" by the process nice value -- MTK
|
.\" by the process nice value -- MTK
|
||||||
.\"
|
.\"
|
||||||
.SS SCHED_DEADLINE: Sporadic task model deadline scheduling
|
.SS SCHED_DEADLINE: Sporadic task model deadline scheduling
|
||||||
SCHED_DEADLINE
|
Since version 3.14, Linux provides a deadline scheduling policy
|
||||||
is currently implemented using GEDF (Global Earliest Deadline First)
|
.RB ( SCHED_DEADLINE ).
|
||||||
with additional CBS (Constant Bandwidth Server).
|
This policy is currently implemented using
|
||||||
|
GEDF (Global Earliest Deadline First)
|
||||||
|
in conjunction with CBS (Constant Bandwidth Server).
|
||||||
|
To set and fetch this policy and associated attributes,
|
||||||
|
one must use the Linux-specific
|
||||||
|
.BR sched_setattr (2)
|
||||||
|
and
|
||||||
|
.BR sched_getattr (2)
|
||||||
|
system calls.
|
||||||
|
|
||||||
A sporadic task is one that has a sequence of jobs, where each
|
A sporadic task is one that has a sequence of jobs, where each
|
||||||
job is activated at most once per period.
|
job is activated at most once per period.
|
||||||
Each job has also a relative deadline,
|
Each job also has a
|
||||||
|
.IR "relative deadline" ,
|
||||||
before which it should finish execution, and a
|
before which it should finish execution, and a
|
||||||
computation time, that is the time necessary for executing the
|
.IR "computation time" ,
|
||||||
job without interruption.
|
which is the CPU time necessary for executing the job.
|
||||||
The instant of time when a task wakes up,
|
The moment when a task wakes up
|
||||||
because a new job has to be executed, is called arrival time
|
because a new job has to be executed is called the
|
||||||
(and it is also referred to as request time or release time).
|
.IR "arrival time"
|
||||||
Start time is instead the time at which a task starts its execution.
|
(also referred to as the request time or release time).
|
||||||
The absolute deadline is thus obtained adding the
|
The
|
||||||
relative deadline to the arrival time.
|
.IR "start time"
|
||||||
|
is the time at which a task starts its execution.
|
||||||
|
The
|
||||||
|
.I "absolute deadline"
|
||||||
|
is thus obtained by adding the relative deadline to the arrival time.
|
||||||
|
|
||||||
The following diagram clarifies these terms:
|
The following diagram clarifies these terms:
|
||||||
|
|
||||||
|
@ -226,16 +239,22 @@ arrival/wakeup absolute deadline
|
||||||
.fi
|
.fi
|
||||||
.in
|
.in
|
||||||
|
|
||||||
|
When setting a
|
||||||
.B SCHED_DEADLINE
|
.B SCHED_DEADLINE
|
||||||
allows the user to specify three parameters (see
|
policy for a thread using
|
||||||
.BR sched_setattr (2)):
|
.BR sched_setattr (2),
|
||||||
Runtime [ns], Deadline [ns] and Period [ns].
|
one can specify three parameters:
|
||||||
Such parameters has not necessarily to correspond to the
|
.IR Runtime ,
|
||||||
aforementioned terms, while usual practise is to set Runtime to
|
.IR Deadline ,
|
||||||
something bigger than the average computation time (or worst-case
|
and
|
||||||
execution time for hard real-time tasks), Deadline to the
|
.IR Period .
|
||||||
relative deadline and Period to the period of the task.
|
These parameters do not necessarily correspond to the aforementioned terms:
|
||||||
With such a setting we would have:
|
usual practice is to set Runtime to something bigger than the average
|
||||||
|
computation time (or worst-case execution time for hard real-time tasks),
|
||||||
|
Deadline to the relative deadline, and Period to the period of the task.
|
||||||
|
Thus, for
|
||||||
|
.BR SCHED_DEADLINE
|
||||||
|
scheduling, we have:
|
||||||
|
|
||||||
.in +4n
|
.in +4n
|
||||||
.nf
|
.nf
|
||||||
|
@ -250,54 +269,88 @@ arrival/wakeup absolute deadline
|
||||||
.fi
|
.fi
|
||||||
.in
|
.in
|
||||||
|
|
||||||
It is checked that: Runtime <= Deadline <= Period.
|
The three deadline-scheduling parameters correspond to the
|
||||||
|
.IR sched_runtime ,
|
||||||
|
.IR sched_deadline ,
|
||||||
|
and
|
||||||
|
.IR sched_period
|
||||||
|
fields of the
|
||||||
|
.I sched_attr
|
||||||
|
structure; see
|
||||||
|
.BR sched_setattr (2).
|
||||||
|
These fields express value in nanoseconds.
|
||||||
|
.\" FIXME It looks as though specifying sched_period as 0 means
|
||||||
|
.\" "make sched_period the same as sched_deadline", right?
|
||||||
|
.\" This needs to be documented.
|
||||||
|
If
|
||||||
|
.IR sched_period
|
||||||
|
is specified as 0, then it is made the same as
|
||||||
|
.IR sched_deadline .
|
||||||
|
|
||||||
|
The kernel requires that:
|
||||||
|
|
||||||
|
sched_runtime <= sched_deadline <= sched_period
|
||||||
|
|
||||||
|
.\" See __checkparam_dl in kernel/sched/core.c
|
||||||
|
In addition, under the current implementation,
|
||||||
|
all of the parameter values must be at least 1024
|
||||||
|
(i.e., just over one microsecond,
|
||||||
|
which is the resolution of the implementation).
|
||||||
|
If any of these checks fails,
|
||||||
|
.BR sched_setattr (2)
|
||||||
|
fails with the error
|
||||||
|
.BR EINVAL .
|
||||||
|
|
||||||
The CBS guarantees non-interference between tasks, by throttling
|
The CBS guarantees non-interference between tasks, by throttling
|
||||||
tasks that attempt to over-run their specified Runtime.
|
threads that attempt to over-run their specified Runtime.
|
||||||
|
|
||||||
In general, the set of all
|
To ensure deadline scheduling guarantees,
|
||||||
|
the kernel must prevent situations where the set of
|
||||||
.B SCHED_DEADLINE
|
.B SCHED_DEADLINE
|
||||||
tasks is not feasible/schedulable within the given constraints.
|
threads is not feasible (schedulable) within the given constraints.
|
||||||
To guarantee some degree of timeliness, we must do an admittance test on
|
The kernel thus performs an admittance test when setting or changing
|
||||||
setting/changing
|
|
||||||
.B SCHED_DEADLINE
|
.B SCHED_DEADLINE
|
||||||
policy/attributes.
|
policy and attributes.
|
||||||
|
This admission test calculates whether the change is feasible;
|
||||||
This admission test calculates that the task set is
|
if it is not
|
||||||
feasible/schedulable, failing this,
|
|
||||||
.BR sched_setattr (2)
|
.BR sched_setattr (2)
|
||||||
will return
|
fails with the error
|
||||||
-EBUSY.
|
.BR EBUSY .
|
||||||
|
|
||||||
For example, it is required (but not necessarily sufficient) for
|
For example, it is required (but not necessarily sufficient) for
|
||||||
the total utilization to be less or equal to the total amount of
|
the total utilization to be less than or equal to the total number of
|
||||||
CPUs available, where, since each task can maximally run for
|
CPUs available, where, since each thread can maximally run for
|
||||||
Runtime per Period, that task's utilization is its
|
Runtime per Period, that thread's utilization is its
|
||||||
Runtime/Period.
|
Runtime divided by its Period.
|
||||||
|
|
||||||
Because we must be able to calculate admittance
|
In order to fulfil the guarantees that are made when
|
||||||
|
a thread is admitted to the
|
||||||
.BR SCHED_DEADLINE
|
.BR SCHED_DEADLINE
|
||||||
tasks are the highest priority (user controllable) tasks in the
|
policy,
|
||||||
system, if any
|
|
||||||
.BR SCHED_DEADLINE
|
.BR SCHED_DEADLINE
|
||||||
task is runnable, it will preempt
|
threads are the highest priority (user controllable) threads in the
|
||||||
any FIFO/RR/OTHER/BATCH/IDLE task.
|
system; if any
|
||||||
|
.BR SCHED_DEADLINE
|
||||||
|
thread is runnable,
|
||||||
|
it will preempt any thread scheduled under one of the other policies.
|
||||||
|
|
||||||
.B SCHED_DEADLINE
|
A call to
|
||||||
tasks will fail
|
|
||||||
.BR fork (2)
|
.BR fork (2)
|
||||||
with
|
by a thread scheduled under the
|
||||||
-EAGAIN,
|
.B SCHED_DEADLINE
|
||||||
except when
|
policy will fail with the error
|
||||||
the forking task hascw
|
.BR EAGAIN ,
|
||||||
SCHED_FLAG_RESET_ON_FORK
|
unless the thread has its reset-on-fork flag set (see below).
|
||||||
set.
|
|
||||||
|
|
||||||
A
|
A
|
||||||
.B SCHED_DEADLINE
|
.B SCHED_DEADLINE
|
||||||
task calling
|
thread that calls
|
||||||
.BR sched_yield (2)
|
.BR sched_yield (2)
|
||||||
will 'yield' the current job and wait for a new period to begin.
|
will yield the current job and wait for a new period to begin.
|
||||||
|
.\"
|
||||||
|
.\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
|
||||||
|
.\" fails with EINVAL, but sched_getscheduler() succeeds.
|
||||||
|
.\" Is that intended? (Why?)
|
||||||
.\"
|
.\"
|
||||||
.\"
|
.\"
|
||||||
.SS SCHED_OTHER: Default Linux time-sharing scheduling
|
.SS SCHED_OTHER: Default Linux time-sharing scheduling
|
||||||
|
@ -421,6 +474,12 @@ matches the real or effective user ID of the target thread
|
||||||
.IR pid )
|
.IR pid )
|
||||||
whose policy is being changed.
|
whose policy is being changed.
|
||||||
|
|
||||||
|
A thread must be privileged
|
||||||
|
.RB ( CAP_SYS_NICE )
|
||||||
|
in order to set or modify a
|
||||||
|
.BR SCHED_DEADLINE
|
||||||
|
policy.
|
||||||
|
|
||||||
Since Linux 2.6.12, the
|
Since Linux 2.6.12, the
|
||||||
.B RLIMIT_RTPRIO
|
.B RLIMIT_RTPRIO
|
||||||
resource limit defines a ceiling on an unprivileged thread's
|
resource limit defines a ceiling on an unprivileged thread's
|
||||||
|
|
Loading…
Reference in New Issue