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:

On the other hand, the sched_setscheduler man page (RHEL 6.1) claims that 99 is the highest:

Which is the highest real-time priority?

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. We have the following in the kernel source file sched.c:

``````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. The following command can be used to invoke a real-time process (the example is how to declare a SCHED RR policy):

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

The following equation is used to calculate the PR value for a real-time process:

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 produces the following result:

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 value. 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

To determine the highest realtime priority you can set programmatically, make use of the sched_get_priority_max function.

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