Linux内核优先级最高,在Linux中,哪个实时优先级是最高优先级

我做了一个实验来钉这个，如下：

> process1：RT优先级= 40，CPU关联性= CPU 0.此过程“旋转”10秒钟，因此它不会让任何低优先级进程在CPU 0上运行。

> process2：RT priority = 39，CPU affinity = CPU 0.这个进程每0.5秒向stdout打印一条消息，睡在之间。它打印每个消息的已用时间。

我运行一个2.6.33内核与PREEMPT_RT补丁。

要运行实验，我在一个窗口中运行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()设置的实时优先级。