在Linux中哪个实时优先级是最高优先级 [英] Which real-time priority is the highest priority in Linux

问题描述

在Linux实时进程优先级范围为1到99的情况下，我不清楚哪个是最高优先级，即1或99.

In the Linux real-time process priority range 1 to 99, it's unclear to me which is the highest priority, 1 or 99.

了解Linux内核"(O'Reilly)的7.2.2节说1是最高优先级，考虑到正常进程的静态优先级从100到139，其中100是最高优先级，这是有道理的:

Section 7.2.2 of "Understanding the Linux Kernel" (O'Reilly) says 1 is the highest priority, which makes sense considering that normal processes have static priorities from 100 to 139, with 100 being the highest priority:

每个实时过程都与一个实时优先级相关联，该优先级的取值范围为1(最高 优先级)到99(最低优先级). "

"Every real-time process is associated with a real-time priority, which is a value ranging from 1 (highest priority) to 99 (lowest priority). "

另一方面，sched_setscheduler手册页(RHEL 6.1)声称最高为99:

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

"根据一种实时策略(SCHED_FIFO，SCHED_RR)调度的进程 的sched_priority值在1(低)到99(高)之间."

"Processes scheduled under one of the real-time policies (SCHED_FIFO, SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high)."

哪个实时优先级最高?

推荐答案

我做了一个实验来确定这一点，如下所示:

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

• 进程1:RT优先级= 40，CPU关联性= CPU0.该进程旋转" 10秒钟，因此它不会让任何较低优先级的进程在CPU 0上运行.

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

进程2:RT优先级= 39，CPU关联性= CPU0.此进程每0.5秒向stdout输出一条消息，并在其间休眠.它将显示每条消息的经过时间.

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.

我正在运行带有PREEMPT_RT补丁的2.6.33内核.

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

要运行实验，我在一个窗口(以root身份)中运行process2，然后在另一个窗口中以process1(以root身份)启动.结果是process1似乎抢占了process2，使它无法运行整整10秒钟.

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.

在第二个实验中，我将process2的RT优先级更改为41.在这种情况下，process2不被process1抢占.

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

此实验表明sched_setscheduler()中的更大 RT优先级值具有更高的优先级.这似乎与Michael Foukarakis从sched.h所指出的相矛盾，但实际上并非如此.在内核源代码的 sched.c 中，我们有:

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)执行以下操作:

rt_mutex_getprio(p) does the following:

return task->normal_prio;

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:

• 使用p-> prio，较小的值将取代较大的值.

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

对于p-> rt_priority，较大的值优先于较小的值.这是使用sched_setscheduler()设置的实时优先级.

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

这篇关于在Linux中哪个实时优先级是最高优先级的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！