Originální popis anglicky:
sched_setscheduler, sched_getscheduler - set and get scheduling
algorithm/parameters
Návod, kniha: Linux Programmer's Manual
#include <sched.h>
int sched_setscheduler(pid_t pid, int policy,
const struct sched_param *p);
int sched_getscheduler(pid_t pid);
struct sched_param {
...
int sched_priority;
...
};
sched_setscheduler sets both the scheduling policy and the associated
parameters for the process identified by
pid. If
pid equals
zero, the scheduler of the calling process will be set. The interpretation of
the parameter
p depends on the selected policy. Currently, the
following three scheduling policies are supported under Linux:
SCHED_FIFO,
SCHED_RR, and
SCHED_OTHER; their respective
semantics are described below.
sched_getscheduler queries the scheduling policy currently applied to the
process identified by
pid. If
pid equals zero, the policy of the
calling process will be retrieved.
The scheduler is the kernel part that decides which runnable process will be
executed by the CPU next. The Linux scheduler offers three different
scheduling policies, one for normal processes and two for real-time
applications. A static priority value
sched_priority is assigned to
each process and this value can be changed only via system calls.
Conceptually, the scheduler maintains a list of runnable processes for each
possible
sched_priority value, and
sched_priority can have a
value in the range 0 to 99. In order to determine the process that runs next,
the Linux scheduler looks for the non-empty list with the highest static
priority and takes the process at the head of this list. The scheduling policy
determines for each process, where it will be inserted into the list of
processes with equal static priority and how it will move inside this list.
SCHED_OTHER is the default universal time-sharing scheduler policy used
by most processes,
SCHED_FIFO and
SCHED_RR are intended for
special time-critical applications that need precise control over the way in
which runnable processes are selected for execution. Processes scheduled with
SCHED_OTHER must be assigned the static priority 0, processes scheduled
under
SCHED_FIFO or
SCHED_RR can have a static priority in the
range 1 to 99. Only processes with superuser privileges can get a static
priority higher than 0 and can therefore be scheduled under
SCHED_FIFO
or
SCHED_RR. The system calls
sched_get_priority_min and
sched_get_priority_max can be used to find out the valid priority range
for a scheduling policy in a portable way on all POSIX.1b conforming systems.
All scheduling is preemptive: If a process with a higher static priority gets
ready to run, the current process will be preempted and returned into its wait
list. The scheduling policy only determines the ordering within the list of
runnable processes with equal static priority.
SCHED_FIFO can only be used with static priorities higher than 0, which
means that when a
SCHED_FIFO processes becomes runnable, it will always
preempt immediately any currently running normal
SCHED_OTHER process.
SCHED_FIFO is a simple scheduling algorithm without time slicing. For
processes scheduled under the
SCHED_FIFO policy, the following rules
are applied: A
SCHED_FIFO process that has been preempted by another
process of higher priority will stay at the head of the list for its priority
and will resume execution as soon as all processes of higher priority are
blocked again. When a
SCHED_FIFO process becomes runnable, it will be
inserted at the end of the list for its priority. A call to
sched_setscheduler or
sched_setparam will put the
SCHED_FIFO (or
SCHED_RR) process identified by
pid at the
start of the list if it was runnable. As a consequence, it may preempt the
currently running process if it has the same priority. (POSIX 1003.1 specifies
that the process should go to the end of the list.) A process calling
sched_yield will be put at the end of the list. No other events will
move a process scheduled under the
SCHED_FIFO policy in the wait list
of runnable processes with equal static priority. A
SCHED_FIFO process
runs until either it is blocked by an I/O request, it is preempted by a higher
priority process, or it calls
sched_yield.
SCHED_RR is a simple enhancement of
SCHED_FIFO. Everything
described above for
SCHED_FIFO also applies to
SCHED_RR, except
that each process is only allowed to run for a maximum time quantum. If a
SCHED_RR process has been running for a time period equal to or longer
than the time quantum, it will be put at the end of the list for its priority.
A
SCHED_RR process that has been preempted by a higher priority process
and subsequently resumes execution as a running process will complete the
unexpired portion of its round robin time quantum. The length of the time
quantum can be retrieved by
sched_rr_get_interval.
SCHED_OTHER can only be used at static priority 0.
SCHED_OTHER is
the standard Linux time-sharing scheduler that is intended for all processes
that do not require special static priority real-time mechanisms. The process
to run is chosen from the static priority 0 list based on a dynamic priority
that is determined only inside this list. The dynamic priority is based on the
nice level (set by the
nice or
setpriority system call) and
increased for each time quantum the process is ready to run, but denied to run
by the scheduler. This ensures fair progress among all
SCHED_OTHER
processes.
A blocked high priority process waiting for the I/O has a certain response time
before it is scheduled again. The device driver writer can greatly reduce this
response time by using a "slow interrupt" interrupt handler.
Child processes inherit the scheduling algorithm and parameters across a
fork.
Memory locking is usually needed for real-time processes to avoid paging delays,
this can be done with
mlock or
mlockall.
As a non-blocking end-less loop in a process scheduled under
SCHED_FIFO
or
SCHED_RR will block all processes with lower priority forever, a
software developer should always keep available on the console a shell
scheduled under a higher static priority than the tested application. This
will allow an emergency kill of tested real-time applications that do not
block or terminate as expected. As
SCHED_FIFO and
SCHED_RR
processes can preempt other processes forever, only root processes are allowed
to activate these policies under Linux.
POSIX systems on which
sched_setscheduler and
sched_getscheduler
are available define
_POSIX_PRIORITY_SCHEDULING in <unistd.h>.
On success,
sched_setscheduler returns zero. On success,
sched_getscheduler returns the policy for the process (a non-negative
integer). On error, -1 is returned,
errno is set appropriately.
- EINVAL
- The scheduling policy is not one of the recognized
policies, or the parameter p does not make sense for the
policy.
- EPERM
- The calling process does not have appropriate privileges
(Linux: does not have the CAP_SYS_NICE capability). Only privileged
processes are allowed to activate the SCHED_FIFO and
SCHED_RR policies. A process calling sched_setscheduler
needs an effective user ID equal to the user ID or effective user ID of
the process identified by pid, or it must be privileged.
- ESRCH
- The process whose ID is pid could not be found.
POSIX.1b (formerly POSIX.4)
Standard Linux is a general-purpose operating system and can handle background
processes, interactive applications, and soft real-time applications
(applications that need to usually meet timing deadlines). This man page is
directed at these kinds of applications.
Standard Linux is
not designed to support hard real-time applications,
that is, applications in which deadlines (often much shorter than a second)
must be guaranteed or the system will fail catastrophically. Like all
general-purpose operating systems, Linux is designed to maximize average case
performance instead of worst case performance. Linux's worst case performance
for interrupt handling is much poorer than its average case, its various
kernel locks (such as for SMP) produce long maximum wait times, and many of
its performance improvement techniques decrease average time by increasing
worst-case time. For most situations, that's what you want, but if you truly
are developing a hard real-time application, consider using hard real-time
extensions to Linux such as RTLinux (http://www.rtlinux.org) or RTAI
(http://www.rtai.org) or use a different operating system designed
specifically for hard real-time applications.
getpriority(2),
mlock(2),
mlockall(2),
munlock(2),
munlockall(2),
nice(2),
sched_get_priority_max(2),
sched_get_priority_min(2),
sched_getaffinity(2),
sched_getparam(2),
sched_rr_get_interval(2),
sched_setaffinity(2),
sched_setparam(2),
sched_yield(2),
setpriority(2),
capabilities(7)
Programming for the real world - POSIX.4 by Bill O. Gallmeister, O'Reilly
& Associates, Inc., ISBN 1-56592-074-0
IEEE Std 1003.1b-1993 (POSIX.1b standard)
ISO/IEC 9945-1:1996 - This is the new 1996 revision of POSIX.1 which
contains in one single standard POSIX.1(1990), POSIX.1b(1993), POSIX.1c(1995),
and POSIX.1i(1995).
