Which Real-Time Priority Is the Highest Priority in Linux

Which real-time priority is the highest priority in Linux

I did an experiment to nail this down, as follows:

• process1: RT priority = 40, CPU affinity = CPU 0. This process "spins" for 10 seconds so it won't let any lower-priority process run on CPU 0.

• process2: RT priority = 39, CPU affinity = CPU 0. This process prints a message to stdout every 0.5 second, sleeping in between. It prints out the elapsed time with each message.

I'm running a 2.6.33 kernel with the PREEMPT_RT patch.

To run the experiment, I run process2 in one window (as root) and then start process1 (as root) in another window. The result is process1 appears to preempt process2, not allowing it to run for a full 10 seconds.

In a second experiment, I change process2's RT priority to 41. In this case, process2 is not preempted by process1.

This experiment shows that a larger RT priority value in sched_setscheduler() has a higher priority. This appears to contradict what Michael Foukarakis pointed out from sched.h, but actually it does not. 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;
        set_load_weight(p);
}

rt_mutex_getprio(p) does the following:

return task->normal_prio;

While normal_prio() happens to do the following:

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

In other words, we have (my own interpretation):

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

Wow! That is confusing! To summarize:

• With p->prio, a smaller value preempts a larger value.

• With p->rt_priority, a larger value preempts a smaller value. This is the real-time priority set using sched_setscheduler().

What is real time priority of a process

if you are using the realtime scheduler (that means if an process runs controlled by the realtime scheduler), so the rtprio could be relevant.
Prio is relevant for the default scheduler sched

Normally RT processes has system-wide the highest priority by default. If you need to tune/coordinate RT processes and non-RT processes, so rtprio and prio have to be tuned.

http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=rtprio
http://linux.die.net/man/2/sched_setscheduler

How to choose thread/process priority in real-time Linux?

What are all these sirq, irq, posixcputmr tasks? Kernel threads?

Yes, all the tasks in brackets are kernel threads.

At what priority should I make my software run?

From 2-69 for normal RT, and 90-98 for your very high priority application threads. The latter will block all IRQ handlers, so try to do as little as possible at high priority. Source

how to identify the priority range in Linux?

The range of priorities supported by the nice utility is always -20 (highest) to 20 (lowest).

Linux SCHED_FIFO not respecting thread priorities

When you start the two threads

// Declare and init thread objects
std::thread thread_1(std::move(task_1), 1, 50000000);
std::thread thread_2(std::move(task_2), 2, 50000000);

they may (!) immediately run and fetch the schedule parameters

// Get information about thread
pthread_getschedparam(pthread_self(), &policy, &sch);

even before you set them with pthread_setschedparam() to another value.
The output might even show 0 and 0, if both threads are scheduled accordingly.

---

The child threads may (!) both be scheduled after the main thread has set the priority. Then you would get the expected output. But any result is possible.

---

When you move pthread_getschedparam() to the end of the thread just before the output, you are more likely to get the expected output of 97 and 98. But even then both threads may run until the end, even before the main thread is scheduled to set the priority.

---

Related Topics