在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（高）之间。”
哪个实时优先级最高？
我做了一个实验来确定这一点，如下所示：
process1：RT优先级= 40，CPU关联性= CPU0。此进程“旋转” 10秒钟，因此它不会让任何较低优先级的进程在CPU 0上运行。
process2：RT优先级= 39，CPU关联性= CPU0。此进程每0.5秒将一条消息打印到stdout，并在它们之间hibernate。它随每条消息一起打印出经过的时间。
我正在运行带有PREEMPT_RT补丁的2.6.33内核。
为了运行实验，我在一个窗口（以root用户身份）中运行process2，然后在另一个窗口中以root用户身份启动process1。结果是进程1似乎抢占了进程2，不允许其运行整整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（）设置的实时优先级。
