Linux中哪个实时优先级最高
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8887531/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Which real-time priority is the highest priority in Linux
提问by David Steinhauer
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 实时进程优先级范围 1 到 99 中，我不清楚哪个是最高优先级，1 还是 99。
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:
“了解 Linux 内核”（O'Reilly）的第 7.2.2 节说 1 是最高优先级，考虑到正常进程的静态优先级从 100 到 139，其中 100 是最高优先级，这是有道理的：
"Every real-time process is associated with a real-time priority, which is a value ranging from 1 (highest priority) to 99 (lowest priority). "
“每个实时进程都与一个实时优先级相关联，它的值范围从 1（最高优先级）到 99（最低优先级）。”
On the other hand, the sched_setscheduler man page (RHEL 6.1) claims that 99 is the highest:
另一方面，sched_setscheduler 手册页 (RHEL 6.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)."
“根据实时策略（SCHED_FIFO、SCHED_RR）之一调度的进程具有 1（低）到 99（高）范围内的 sched_priority 值。”
Which is the highest real-time priority?
哪个实时优先级最高？
采纳答案by David Steinhauer
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.
进程 1：RT 优先级 = 40，CPU 关联性 = CPU 0。此进程“旋转”10 秒，因此不会让任何低优先级进程在 CPU 0 上运行。
进程 2：RT 优先级 = 39，CPU 关联性 = CPU 0。此进程每 0.5 秒向 stdout 打印一条消息，并在中间休眠。它打印出每条消息的经过时间。
I'm running a 2.6.33 kernel with the PREEMPT_RT patch.
我正在运行带有 PREEMPT_RT 补丁的 2.6.33 内核。
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（以 root 身份），然后在另一个窗口中启动 process1（以 root 身份）。结果是 process1 似乎抢占了 process2，不允许它运行整整 10 秒。
In a second experiment, I change process2's RT priority to 41. In this case, process2 is notpreempted by process1.
在第二个实验中，我将 process2 的 RT 优先级更改为 41。在这种情况下，process2没有被 process1 抢占。
This experiment shows that a largerRT 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.cin the kernel source, we have:
这个实验表明sched_setscheduler() 中的 RT 优先级值越大，优先级越高。这似乎与 Michael Fokarakis 从 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) does the following:
rt_mutex_getprio(p) 执行以下操作：
return task->normal_prio;
While normal_prio() happens to do the following:
虽然 normal_prio() 恰好执行以下操作：
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().
对于 p->prio，较小的值会抢占较大的值。
使用 p->rt_priority，较大的值会抢占较小的值。这是使用 sched_setscheduler() 设置的实时优先级。
回答by Ahmed Masud
Your assumption that normal processes have static priorities from 100 to 139 is volatile at best and invalid at worst. What I mean is that: set_scheduler only allows the sched_priority to be 0 (which indicates dynamic priority scheduler) with SCHED_OTHER / SCHED_BATCH and SCHED_IDLE (true as of 2.6.16).
您对正常进程的静态优先级从 100 到 139 的假设充其量是不稳定的，最坏的情况是无效的。我的意思是：set_scheduler 只允许 sched_priority 为 0（表示动态优先级调度程序）与 SCHED_OTHER / SCHED_BATCH 和 SCHED_IDLE（自 2.6.16 起为真）。
Programmatically static priorities are 1-99 only for SCHED_RR and SCHED_FIFO
仅 SCHED_RR 和 SCHED_FIFO 的编程静态优先级为 1-99
Now you may see priorities from 100-139 being used internally by a dynamic scheduler howeve,r what the kernel does internally to manage dynamic priorities (including flipping the meaning of high vs. low priority to make the comparison or sorting easier) should be opaque to the user-space.
现在您可能会看到动态调度程序在内部使用 100-139 之间的优先级，但是内核在内部为管理动态优先级所做的工作（包括翻转高优先级与低优先级的含义以使比较或排序更容易）应该是不透明的到用户空间。
Remember in SCHED_OTHER you are mostly stuffing the processes in the same priority queue.
请记住，在 SCHED_OTHER 中，您主要将进程塞入同一优先级队列中。
The idea is to make kernel easier to debug and avoid goofy out-of-bound mistakes.
这个想法是让内核更容易调试并避免愚蠢的越界错误。
So the rationale in switching the meaning could be that as a kernel developer don't want to use math like 139-idx (just in case idx > 139) ... it is better to do math with idx-100 and reverse the concept of low vs. high because idx < 100 is well understood.
因此，转换含义的基本原理可能是作为内核开发人员不想使用像 139-idx 这样的数学（以防万一 idx > 139）……最好使用 idx-100 进行数学运算并反转概念低与高，因为 idx < 100 很好理解。
Also a side effect is that niceness becomes easier to deal with. 100 - 100 <=> nice == 0; 101-100 <=> nice == 1; etc. is easier. It collapses to negative numbers nicely as well (NOTHING to do with static priorities) 99 - 100 <=> nice == -1 ...
还有一个副作用是友善变得更容易处理。100 - 100 <=> 不错 == 0; 101-100 <=> 不错 == 1; 等更容易。它也很好地折叠为负数（与静态优先级无关）99 - 100 <=> nice == -1 ...
回答by Pawel
To determine the highest realtime priority you can set programmatically, make use of the sched_get_priority_max function.
要确定您可以以编程方式设置的最高实时优先级，请使用 sched_get_priority_max 函数。
On Linux 2.6.32 a call to sched_get_priority_max(SCHED_FIFO) returns 99.
在 Linux 2.6.32 上，调用 sched_get_priority_max(SCHED_FIFO) 返回 99。
回答by Michael Foukarakis
This comment in sched.his pretty definitive:
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.
*/
Note this part:
注意这部分：
Priority values are inverted: lower p->priovalue means higher priority.
优先级值颠倒：较低的p->prio值意味着较高的优先级。
回答by Sturdyone
- Absolutely, the realtime priority is applicable to the RT policies FIFO and RR which varies from 0-99.
We do have the 40 as a count of the non real time process priority for BATCH, OTHER policies which varies from 0-39 not from 100 to 139. This, you can observe by looking at any process in the system which is not a realtime process. It will bear a PR of 20 and NIceness of 0 by default. If you decrease the niceness of a process (usually, lower or negative the number lesser the niceness, more hungry the process), say from 0 to -1, you 'll observe that the PRiority will drop to 19 from 20. This simply tells that, if you make a process more hungry or would like to get a little more attention by decreasing the niceness value of the PID you 'll get decrease in priority too, thus lower the PRIORITY number HIGHER the 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
- 当然，实时优先级适用于从 0-99 变化的 RT 策略 FIFO 和 RR。
我们确实有 40 作为 BATCH 的非实时进程优先级的计数，其他策略从 0-39 不等，而不是从 100 到 139。这一点，您可以通过查看系统中的任何非实时进程来观察过程。默认情况下，它的 PR 为 20，NIceness 为 0。如果你降低一个进程的 niceness（通常，降低或负数，niceness 越小，进程越饿），比如从 0 到 -1，你会观察到优先级将从 20 下降到 19。这只是告诉也就是说，如果你让一个进程更饿，或者想通过降低 PID 的 niceness 值来获得更多的关注，你的优先级也会降低，从而降低优先级数，提高优先级。
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
Hope this practical example clarifies the doubts and may help fix the words at incorrect source, if any.
希望这个实际例子能澄清疑虑，并可能有助于修正来源不正确的单词（如果有的话）。
回答by Agustin Barrachina
Short Answer
简答
99 will be the winner for real time priority.
99 将成为实时优先级的赢家。
PR is the priority level (range -100 to 40). The lower the PR, the higher the priority of the process will be.
PR 是优先级（范围 -100 到 40）。PR 越低，进程的优先级就越高。
PR is calculated as follows:
PR 计算如下：
- for normal processes: PR = 20 - NI (NI is nice and ranges from -20 to 19)
- for real time processes: PR = - 1 - real_time_priority (real_time_priority ranges from 1 to 99)
- 对于正常进程：PR = 20 - NI（NI 很好，范围从 -20 到 19）
- 对于实时进程：PR = - 1 - real_time_priority（real_time_priority 范围从 1 到 99）
Long Answer
长答案
There are 2 types of processes, the normalones and the real timeFor the normal ones (and only for those), nice is applied as follows:
有两种类型的进程，正常进程和实时进程对于正常进程 （并且仅用于那些进程），nice 应用如下：
Nice
好的
The "niceness" scale goes from -20 to 19, whereas -20 it's the highest priority and 19 the lowest priority. The priority level is calculated as follows:
“友好”等级从 -20 到 19，而 -20 是最高优先级，19 是最低优先级。优先级计算如下：
PR = 20 + NI
PR = 20 + NI
Where NI is the nice level and PR is the priority level. So as we can see, the -20 actually maps to 0, while the 19 maps to 39.
其中NI是nice级别，PR是优先级别。所以我们可以看到，-20 实际上映射到 0，而 19 映射到 39。
By default, a program nice value is 0 bit it is possible for a root user to lunch programs with a specified nice value by using the following command:
默认情况下，程序 nice 值是 0 位，root 用户可以使用以下命令使用指定的 nice 值午餐程序：
nice -n <nice_value> ./myProgram
Real Time
即时的
We could go even further. The nice priority is actually used for user programs. Whereas the UNIX/LINUX overall priority has a range of 140 values, nice value enables the process to map to the last part of the range (from 100 to 139). This equation leaves the values from 0 to 99 unreachable which will correspond to a negative PR level (from -100 to -1). To be able to access to those values, the process should be stated as "real time".
我们还可以走得更远。nice 优先级实际上用于用户程序。UNIX/LINUX 总体优先级的范围为 140 个值，而 nice 值使进程能够映射到范围的最后一部分（从 100 到 139）。该等式使 0 到 99 之间的值无法达到，这将对应于负 PR 级别（从 -100 到 -1）。为了能够访问这些值，该过程应声明为“实时”。
There are 5 scheduling policies in a LINUX environment that can be displayed with the following command:
LINUX环境下有5种调度策略，可以通过以下命令显示：
chrt -m
Which will show the following list:
这将显示以下列表：
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 processes could be divided into 2 groups, the normal scheduling policies (1 to 3) and the real time scheduling policies (4 and 5). The real time processes will always have priority over normal processes. A real time process could be called using the following command (The example is how to declare a SCHED_RR policy):
调度过程可以分为2组，正常调度策略（1到3）和实时调度策略（4和5）。实时进程总是优先于正常进程。可以使用以下命令调用实时进程（示例是如何声明 SCHED_RR 策略）：
chrt --rr <priority between 1-99> ./myProgram
To obtain the PR value for a real time process the following equation is applied:
要获得实时过程的 PR 值，请应用以下等式：
PR = -1 - rt_prior
PR = -1 - rt_prior
Where rt_prior corresponds to the priority between 1 and 99. For that reason the process which will have the higher priority over other processes will be the one called with the number 99.
其中 rt_prior 对应于 1 到 99 之间的优先级。因此，优先级高于其他进程的进程将是编号为 99 的进程。
It is important to note that for real time processes, the nice value is not used.
需要注意的是，对于实时进程，不使用 nice 值。
To see the current "niceness" and PR value of a process the following command can be executed:
要查看进程的当前“niceness”和 PR 值，可以执行以下命令：
top
Which shows the following output:
这显示了以下输出：
In the figure the PR and NI values are displayed. It is good to note the process with PR value -51 that corresponds to a real time value. There are also some processes whose PR value is stated as "rt". This value actually corresponds to a PR value of -100.
图中显示了 PR 和 NI 值。最好注意 PR 值为 -51 的过程，该过程对应于实时值。也有一些进程的 PR 值表示为“rt”。该值实际上对应于 -100 的 PR 值。
回答by Rohit B
Linux Kernel implements two separate priority ranges -
Linux 内核实现了两个独立的优先级范围 -
Nice value: -20 to +19; largernice values correspond to lower priority.
Real-time priority: 0 to 99; higherreal-time priority values correspond to a greater priority.
尼斯值：-20 到 +19；较大的nice 值对应于较低的优先级。
实时优先级：0～99；较高的实时优先级值对应较高的优先级。
