GNU Info

(libc.info)Absolute Priority

---

Next: Realtime Scheduling Up: Priority

---

Enter node , (file) or (file)node

Absolute Priority
-----------------

   Every process has an absolute priority, and it is represented by a
number.  The higher the number, the higher the absolute priority.

   On systems of the past, and most systems today, all processes have
absolute priority 0 and this section is irrelevant.  In that case,
Note: Traditional Scheduling.  Absolute priorities were invented to
accommodate realtime systems, in which it is vital that certain
processes be able to respond to external events happening in real time,
which means they cannot wait around while some other process that _wants
to_, but doesn't _need to_ run occupies the CPU.

   When two processes are in contention to use the CPU at any instant,
the one with the higher absolute priority always gets it.  This is true
even if the process with the lower priority is already using the CPU
(i.e. the scheduling is preemptive).  Of course, we're only talking
about processes that are running or "ready to run," which means they are
ready to execute instructions right now.  When a process blocks to wait
for something like I/O, its absolute priority is irrelevant.

   *Note:*  The term "runnable" is a synonym for "ready to run."

   When two processes are running or ready to run and both have the same
absolute priority, it's more interesting.  In that case, who gets the
CPU is determined by the scheduling policy.  If the processes have
absolute priority 0, the traditional scheduling policy described in
Note: Traditional Scheduling applies.  Otherwise, the policies
described in Note: Realtime Scheduling apply.

   You normally give an absolute priority above 0 only to a process that
can be trusted not to hog the CPU.  Such processes are designed to block
(or terminate) after relatively short CPU runs.

   A process begins life with the same absolute priority as its parent
process.  Functions described in Note: Basic Scheduling Functions can
change it.

   Only a privileged process can change a process' absolute priority to
something other than `0'.  Only a privileged process or the target
process' owner can change its absolute priority at all.

   POSIX requires absolute priority values used with the realtime
scheduling policies to be consecutive with a range of at least 32.  On
Linux, they are 1 through 99.  The functions `sched_get_priority_max'
and `sched_set_priority_min' portably tell you what the range is on a
particular system.

Using Absolute Priority
.......................

   One thing you must keep in mind when designing real time
applications is that having higher absolute priority than any other
process doesn't guarantee the process can run continuously.  Two things
that can wreck a good CPU run are interrupts and page faults.

   Interrupt handlers live in that limbo between processes.  The CPU is
executing instructions, but they aren't part of any process.  An
interrupt will stop even the highest priority process.  So you must
allow for slight delays and make sure that no device in the system has
an interrupt handler that could cause too long a delay between
instructions for your process.

   Similarly, a page fault causes what looks like a straightforward
sequence of instructions to take a long time.  The fact that other
processes get to run while the page faults in is of no consequence,
because as soon as the I/O is complete, the high priority process will
kick them out and run again, but the wait for the I/O itself could be a
problem.  To neutralize this threat, use `mlock' or `mlockall'.

   There are a few ramifications of the absoluteness of this priority
on a single-CPU system that you need to keep in mind when you choose to
set a priority and also when you're working on a program that runs with
high absolute priority.  Consider a process that has higher absolute
priority than any other process in the system and due to a bug in its
program, it gets into an infinite loop.  It will never cede the CPU.
You can't run a command to kill it because your command would need to
get the CPU in order to run.  The errant program is in complete
control.  It controls the vertical, it controls the horizontal.

   There are two ways to avoid this: 1) keep a shell running somewhere
with a higher absolute priority.  2) keep a controlling terminal
attached to the high priority process group.  All the priority in the
world won't stop an interrupt handler from running and delivering a
signal to the process if you hit Control-C.

   Some systems use absolute priority as a means of allocating a fixed
percentage of CPU time to a process.  To do this, a super high priority
privileged process constantly monitors the process' CPU usage and raises
its absolute priority when the process isn't getting its entitled share
and lowers it when the process is exceeding it.

   *Note:*  The absolute priority is sometimes called the "static
priority."  We don't use that term in this manual because it misses the
most important feature of the absolute priority:  its absoluteness.