哪个实时优先级是Linux中最高优先级

Question

在Linux实时进程优先级范围1到99中，我不清楚哪个是最高优先级，1或99。

“理解Linux内核”（O'Reilly）的第7.2.2节说1是最高优先级，考虑到正常进程具有从100到139的静态优先级，其中100是最高优先级，这是有意义的：

“每个实时进程都与实时优先级相关联，实时优先级是从1（最高优先级）到99（最低优先级）的值。”

另一方面，sched_setscheduler手册页（RHEL 6.1）声称99是最高的：

“在一个实时策略（SCHED_FIFO，SCHED_RR）下调度的进程的sched_priority值在1（低）到99（高）范围内。”

哪个是最高的实时优先级？

Answer 1

我做了一个实验来解决这个问题，如下：

• process1：RT优先级= 40，CPU亲和力= CPU 0.此进程“旋转”10秒，因此不会让任何低优先级进程在CPU 0上运行。
• process2：RT优先级= 39，CPU亲和力= CPU 0.此过程每0.5秒向stdout输出一条消息，介于两者之间。它打印出每条消息的已用时间。

我正在使用PREEMPT_RT补丁运行2.6.33内核。

要运行实验，我在一个窗口（以root身份）运行process2，然后在另一个窗口中启动process1（以root身份）。结果是process1似乎抢占了process2，不允许它运行整整10秒。

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

此实验表明sched_setscheduler（）中较大的RT优先级值具有较高的优先级。这似乎与Michael Foukarakis从sched.h中指出的内容相矛盾，但事实上并非如此。在内核源代码中的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;
        set_load_weight(p);
}

rt_mutex_getprio（p）执行以下操作：

return task->normal_prio;

虽然normal_prio（）碰巧执行以下操作：

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

换句话说，我们（我自己的解释）：

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

哇！那令人困惑！总结一下：

• 使用p-> prio时，较小的值会抢占较大的值。
• 使用p-> rt_priority时，较大的值会抢占较小的值。这是使用sched_setscheduler（）设置的实时优先级。

Answer 2

sched.h中的这条评论非常明确：

/*
 * 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.
 */

注意这部分：

优先级值被反转：较低的p->prio值意味着更高的优先级。

Answer 3

要确定可以以编程方式设置的最高实时优先级，请使用sched_get_priority_max函数。

在Linux 2.6.32上，对sched_get_priority_max（SCHED_FIFO）的调用返回99。

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

Answer 4

简答

99将成为实时优先的赢家。

PR是优先级（范围-100到40）。 PR越低，该过程的优先级越高。

PR的计算方法如下：

• 对于正常过程：PR = 20 - NI（NI很好，范围从-20到19）
• 对于实时进程：PR = - 1 - real_time_priority（real_time_priority范围从1到99）

答案很长

有两种类型的进程，正常进程和实时对于正常进程（仅适用于那些进程），nice应用如下：

尼斯

“漂亮”标度从-20到19，而-20是最高优先级，19是最低优先级。优先级计算如下：

到PR = 20 +

NI是最好的水平，PR是优先级。我们可以看到，-20实际上映射到0，而19映射到39。

默认情况下，程序nice值为0 bit，root用户可以使用以下命令为具有指定nice值的程序提供午餐：

nice -n <nice_value> ./myProgram 

即时的

我们可以走得更远。优先级实际上用于用户程序。 UNIX / LINUX总体优先级的范围为140个值，而nice值使进程能够映射到范围的最后部分（从100到139）。该等式使得0到99之间的值不可达，这将对应于负PR级别（从-100到-1）。为了能够访问这些值，该过程应该被称为“实时”。

LINUX环境中有5个调度策略，可以使用以下命令显示：

chrt -m 

这将显示以下列表：

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

调度过程可以分为2组，正常调度策略（1到3）和实时调度策略（4和5）。实时流程始终优先于正常流程。可以使用以下命令调用实时进程（示例是如何声明SCHED_RR策略）：

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

要获得实时过程的PR值，应用以下等式：

On = -1 - Rated_prayer

其中rt_prior对应于1到99之间的优先级。因此，具有比其他进程更高优先级的进程将是使用数字99调用的进程。

重要的是要注意，对于实时进程，不使用nice值。

要查看进程的当前“niceness”和PR值，可以执行以下命令：

top

其中显示以下输出：

在图中，显示PR和NI值。值得注意的是PR值-51对应于实时值的过程。还有一些进程的PR值表示为“rt”。该值实际上对应于PR值-100。

Answer 5

您假设正常过程具有从100到139的静态优先级，这种假设最多是挥发性的，最坏的情况下无效。我的意思是：set_scheduler只允许sched_priority为0（表示动态优先级调度程序），SCHED_OTHER / SCHED_BATCH和SCHED_IDLE（从2.6.16开始为真）。

程序化静态优先级仅为SCHED_RR和SCHED_FIFO的1-99

现在你可能会看到动态调度程序内部使用100-139的优先级，内核管理动态优先级的内容（包括翻转高优先级和低优先级的含义以使比较或排序更容易）应该是不透明的到用户空间。

请记住，在SCHED_OTHER中，您主要将进程填充到同一优先级队列中。

我们的想法是让内核更容易调试并避免愚蠢的越界错误。

因此，切换含义的基本原理可能是内核开发人员不想使用像139-idx这样的数学（只是在idx> 139的情况下）......最好用idx-100进行数学运算并反转这个概念低和高，因为idx <100是很好理解的。

另外一个副作用是，好处变得更容易处理。 100 - 100 <=>不错== 0; 101-100 <=>不错== 1;等等更容易。它也很好地折叠到负数（没有与静态优先级相关）99 - 100 <=> nice == -1 ...

Answer 6

1. 当然，实时优先级适用于RT策略FIFO和RR，其范围为0-99。
2. 我们确实有40作为BATCH的非实时进程优先级的计数，其他策略从0-39而不是从100到139变化。这样，您可以通过查看系统中不是实时的任何进程来观察处理。默认情况下它的PR为20，NIceness为0。如果你降低了一个过程的好处（通常，较低或负数的数字较小，那个过程更加饥饿），比如从0到-1，你会发现PRiority会从20降到19。这只是告诉你如果你让一个过程更加饥饿，或者想通过降低PID的漂亮度值来获得更多关注，那么你的优先级也会降低，从而降低PRIORITY数量的优先级。

   Example:
   
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   2079 admin     10 -10  280m  31m 4032 S  9.6  0.0  21183:05 mgmtd
   [[email protected] ~]# renice -n -11 2079
   2079: old priority -10, new priority -11
   [[email protected] ~]# top -b | grep mgmtd
   2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
   ^C

希望这个实际例子能够澄清疑虑，并且可能有助于修正错误来源的单词，如果有的话。