最高優先級在Linux實時進程的優先級範圍爲1〜99，這是我不清楚這是最高優先級，1個或99哪個實時優先級是在Linux中
7.2.2節「深入理解Linux內核」（O'Reilly出版）說，1爲最高優先級，這是有道理的考慮到正常的進程從100到139的靜態優先級，100爲最高優先級：
「每一個實實時過程與實時優先級相關聯，實時優先級是範圍從1（最高優先級 優先級）到99（最低優先級）的值。「
在另一方面，sched_setscheduler手冊頁（RHEL 6.1）聲稱，99是最高的：實時策略之一下安排
「進程（SCHED_FIFO，SCHED_RR） 有sched_priority值的範圍爲1（低）到99（高）。「
這是最高的實時優先級？
我做了一個實驗釘下來，如下所示：
過程1：RT優先= 40，CPU親和力= CPU 0。此過程「旋轉」 10秒，所以它不會讓在CPU 0上運行的任何優先級較低的進程。
進程2：RT優先級= 39，CPU關聯性= CPU 0.此進程每隔0.5秒打印一條消息到標準輸出，並在兩者之間休眠。它會顯示每條消息的已用時間。
我使用PREEMPT_RT補丁運行2.6.33內核。
要運行實驗，我在一個窗口中運行process2（以root身份），然後在另一個窗口中啓動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（）設置的實時優先級。
你的假設，即正常過程具有靜態優先級從100到139是最好的揮發性和無效在最壞的情況。我的意思是：set_scheduler只允許SCHED_OTHER/SCHED_BATCH和SCHED_IDLE（從2.6.16起爲true）的sched_priority爲0（表示動態優先級調度程序）。
編程靜態優先級爲1-99只爲SCHED_RR和SCHED_FIFO
現在你可以看到從100-139的優先級被動態調度內部使用howeve，r表示什麼內核是在內部管理動態優先級（包括翻轉高優先級與低優先級的含義以使比較或排序更容易）應該對用戶空間不透明。
記得在SCHED_OTHER你大多餡的過程中相同的優先級隊列。
的想法是讓內核更容易調試，避免愚蠢的亂約束錯誤。
因此，切換意義的理由可能是因爲內核開發人員不想使用像139-idx這樣的數學（只是爲了防止idx> 139）......最好是用idx-100做數學並扭轉低與高的概念，因爲很好理解idx < 100。
另外一個副作用是，美好的事物變得更容易處理。 100 - 100 < =>不錯== 0; 101-100 < =>不錯== 1;等等更容易。它很好地摺疊到負數（沒有與靜態優先級相關）99 - 100 < =>不錯== -1 ...
好的，我看到sched_priority與靜態優先級不同，並且所有非實時進程的sched_priority都是0. – 2012-01-17 15:35:21
因此，靜態優先級隻影響實時進程的時間段。我認爲sched_priority是O'Reilly書中所稱的「實時優先級」。如果是這樣，那麼O'Reilly的書就會落後。所以，回到我原來的問題：99是最高優先級的sched_priority，還是1是最高優先級？ – 2012-01-17 15:57:05
要確定最高的實時優先級，您可以通過編程設置，使用sched_get_priority_max功能。
在Linux 2.6.32調用sched_get_priority_max（SCHED_FIFO）返回99。
更多相關的業務方案的問題，從同一手冊頁：「與數值較高優先級值過程與數值較低的優先級值過程之前預定」。 – davmac 2016-01-20 09:06:14
在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值意味着更高的優先級。
我們有40個同批處理非實時進程優先級的計數，其他政策從0-39不是從100到139這個變化，你可以通過查看系統中的任何過程中觀察哪些不是一個實時過程。默認情況下，它將承擔20的PR和NIceness 0。如果減少進程的nice值（通常較低或負數量較少的美好的事物，更飢餓的過程），說從0到-1，你會觀察到，將優先從20 這只是下降到19告訴，如果你犯了一個過程更餓了，或想通過降低PID你「的正派價值優先級會得到降低太多，以獲得更多一點的關注，從而降低優先級編號，優先級越高。
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
希望這個實際例子闡明瞭懷疑，並可以幫助解決在不正確源的話，如果有的話。
+1爲研究工作！ – Haywire 2013-05-09 15:03:38