lkml.org 
[lkml]   [2014]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[SCHED_DEADLINE man pages 2/2] sched(7) SCHED_DEADLINE
Hello Peter et al.

Here is the section of the sched(7) page that describes SCHED_DEADLINE,
as rendered text, with the (entire) raw page source attached. Please
carefully review.

Cheers,

Michael

SCHED_DEADLINE: Sporadic task model deadline scheduling
Since version 3.14, Linux provides a deadline scheduling pol‐
icy (SCHED_DEADLINE). 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-spe‐
cific sched_setattr(2) and sched_getattr(2) system calls.

A sporadic task is one that has a sequence of jobs, where
each job is activated at most once per period. Each job also
has a relative deadline, before which it should finish execu‐
tion, and a computation time, which is the CPU time necessary
for executing the job. The moment when a task wakes up
because a new job has to be executed is called the arrival
time (also referred to as the request time or release time).
The start time is the time at which a task starts its execu‐
tion. The absolute deadline is thus obtained by adding the
relative deadline to the arrival time.

The following diagram clarifies these terms:

arrival/wakeup absolute deadline
| start time |
| | |
v v v
-----x--------xooooooooooooooooo-------x--------x---
|<- comp. time ->|
|<------- relative deadline ----->|
|<-------------- period ------------------>|

When setting a SCHED_DEADLINE policy for a thread using
sched_setattr(2), one can specify three parameters: Runtime,
Deadline, and Period. These parameters do not necessarily
correspond to the aforementioned terms: 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 SCHED_DEADLINE scheduling, we have:

arrival/wakeup absolute deadline
| start time |
| | |
v v v
-----x--------xooooooooooooooooo-------x--------x---
|<-- Runtime --->|
|<----------- Deadline ---------->|
|<-------------- Period ------------------>|

The three deadline-scheduling parameters correspond to the
sched_runtime, sched_deadline, and sched_period fields of the
sched_attr structure; see sched_setattr(2). These fields
express value in nanoseconds. If sched_period is specified
as 0, then it is made the same as sched_deadline.

The kernel requires that:

sched_runtime <= sched_deadline <= sched_period

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, sched_setattr(2) fails with the
error EINVAL.

The CBS guarantees non-interference between tasks, by throt‐
tling threads that attempt to over-run their specified Run‐
time.

To ensure deadline scheduling guarantees, the kernel must
prevent situations where the set of SCHED_DEADLINE threads is
not feasible (schedulable) within the given constraints. The
kernel thus performs an admittance test when setting or
changing SCHED_DEADLINE policy and attributes. This admis‐
sion test calculates whether the change is feasible; if it is
not sched_setattr(2) fails with the error EBUSY.

For example, it is required (but not necessarily sufficient)
for the total utilization to be less than or equal to the
total number of CPUs available, where, since each thread can
maximally run for Runtime per Period, that thread's utiliza‐
tion is its Runtime divided by its Period.

In order to fulfil the guarantees that are made when a thread
is admitted to the SCHED_DEADLINE policy, SCHED_DEADLINE
threads are the highest priority (user controllable) threads
in the system; if any SCHED_DEADLINE thread is runnable, it
will preempt any thread scheduled under one of the other
policies.

A call to fork(2) by a thread scheduled under the SCHED_DEAD‐
LINE policy will fail with the error EAGAIN, unless the
thread has its reset-on-fork flag set (see below).

A SCHED_DEADLINE thread that calls sched_yield(2) will yield
the current job and wait for a new period to begin.

--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[unhandled content-type:application/x-troff-man]
\
 
 \ /
  Last update: 2014-05-13 18:41    [W:0.231 / U:1.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site