# In Linux, which real-time priority is the most important?

## Problem

I’m not sure which is the highest priority in the Linux real-time process priority range of 1 to 99.

According to section 7.2.2 of O’Reilly’s “Understanding the Linux Kernel,” 1 is the highest priority, which makes sense given that normal processes have fixed priorities ranging from 100 to 139, with 100 being the highest:

The sched setscheduler man page (RHEL 6.1) asserts, however, that 99 is the highest:

Which of the following has the highest priority in real time?

## Solution #1

To prove my point, I conducted the following experiment:

I’m using the PREEMPT RT patch on a 2.6.33 kernel.

To do the experiment, I start process2 (as root) in one window and process1 (as root) in another. Process1 appears to preempt process2, preventing it from running for the entire 10 seconds.

In a second experiment, I set the RT priority of process2 to 41. Process2 is not preempted by process1 in this situation.

This experiment illustrates that a greater priority is assigned to a larger RT priority value in sched setscheduler(). This appears to be in conflict with what Michael Foukarakis pointed out in sched.h, but it isn’t. In sched.c in the kernel source, we have:

``````static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
BUG_ON(p->se.on_rq);

p->policy = policy;
p->rt_priority = prio;
p->normal_prio = normal_prio(p);
/* we are holding p->pi_lock already */
p->prio = rt_mutex_getprio(p);
if (rt_prio(p->prio))
p->sched_class = &rt_sched_class;
else
p->sched_class = &fair_sched_class;
}
``````

The function rt mutex getprio(p) performs the following:

``````return task->normal_prio;
``````

Normal prio(), on the other hand, does the following:

``````prio = MAX_RT_PRIO-1 - p->rt_priority;  /* <===== notice! */
...
return prio;
``````

To put it another way, we have (my interpretation):

``````p->prio = p->normal_prio = MAX_RT_PRIO - 1 - p->rt_priority
``````

Wow! That’s perplexing! To sum it up:

## Solution #2

For real-time priority, 99 will be the winner.

The priority level is PR (range -100 to 39). The process will have a greater priority if the PR is low.

The following formula is used to compute PR:

There are two sorts of processes: regular and real-time. Nice is applied to the normal ones (and only those) like follows:

Nice

The “niceness” scale ranges from -20 to 19, with -20 indicating the highest importance and 19 indicating the lowest. The following formula is used to determine the priority level:

PR + NI = PR + PR + PR + PR + PR + PR + PR +

The lovely level is NI, while the priority level is PR. As can be seen, the -20 corresponds to 0 whereas the 19 corresponds to 39.

By default, a program’s nice value is 0 bit; however, a root user can use the following command to lunch programs with a defined lovely value:

``````nice -n <nice_value> ./myProgram
``````

Real Time

We could take it a step farther. The pleasant priority is used for user programs. The overall priority of UNIX/LINUX has a range of 140 values, but good value allows the process to map to the final portion of the range (from 100 to 139). The values 0 to 99 are unattainable in this equation, resulting in a negative PR level (from -100 to -1). The procedure should be stated as “real time” in order to gain access to such values.

In a LINUX environment, there are five scheduling policies that can be viewed with the command:

``````chrt -m
``````

The following list will appear:

``````1. SCHED_OTHER   the standard round-robin time-sharing policy
2. SCHED_BATCH   for "batch" style execution of processes
3. SCHED_IDLE    for running very low priority background jobs.
4. SCHED_FIFO    a first-in, first-out policy
5. SCHED_RR      a round-robin policy
``````

The scheduling policies can be classified into two categories: standard scheduling policies (1–3) and real-time scheduling policies (4 and 5). Real-time processes will always take precedence over standard processes. A real time process could be called using the following command (The example is how to declare a SCHED_RR policy):

``````chrt --rr <priority between 1-99> ./myProgram
``````

To obtain the PR value for a real time process the following equation is applied:

rt prior = -1 PR = -1 PR = -1 PR = -1 PR = -1 PR = -1 PR =

Where rt prior is the priority number between 1 and 99. As a result, the procedure designated with the number 99 will take precedence over all others.

It’s worth noting that the good value isn’t used in real-time activities.

The following command can be used to see the current “niceness” and PR value of a process:

``````top
``````

Which shows the following output:

The PR and NI values are shown in the diagram. It’s worth noting the process with PR value -51, which is a real-time number. There are also some processes with a PR value of “rt.” In reality, this figure translates to a PR of -100.

## Solution #3

The following comment in sched.h is quite conclusive:

``````/*
* Priority of a process goes from 0..MAX_PRIO-1, valid RT
* priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
* tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority
* values are inverted: lower p->prio value means higher priority.
*
* The MAX_USER_RT_PRIO value allows the actual maximum
* RT priority to be separate from the value exported to
* user-space.  This allows kernel threads to set their
* priority to a value higher than any user task. Note:
* MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
*/
``````

Note this part:

The order of priority is inverted: a lower p->prio value indicates a higher priority.

## Solution #4

Use the sched get priority max method to find the highest realtime priority you can assign programmatically.

A call to sched get priority max(SCHED FIFO) on Linux 2.6.32 returns 99.

See http://linux.die.net/man/2/sched_get_priority_max