最近在优化RTlinux的实时APP，在各种资料之间查找关于linux优先级的相关资料，终于对linux进程优先级有一些了解。
首先在linux中优先级级别只有0-139这140个级别，这是固定的，数字越小优先级别越高，所以优先级为0的进程具有最高优先级。linux进程分为实时进程和非实时进程，这140个优先级中，linux把0-99分配给实时进程，100-139分配给非实时的普通进程，所以实时进程的优先级总是比非实时的普通进程要高，大部分情况下我们所用到的用户进程都是非实时的普通进程，用户进程都是在100-139这个优先级相对较低的范围折腾。
linux的进程调度策略分为FIFO，RR，和OTHER（NORMAL）三种。实时进程使用FIFO或RR调度，非实时进程使用OTHER调度。实时进程调度策略（FIFO，RR）和非实时进程调度策略上的主要不同点在于FIFO和RR在有高优先级进程的情况下，低优先级进程不可能运行。FIFO调度的特点是在没有更高优先级进程出现或主动释放CPU的情况下，进程可以一直运行，直到任务结束。RR调度将同优先级的进程放到一个队列，在没有更高优先级进程的情况下同优先级的进程公平分配CPU时间，也就是说相比于FIFO，RR调度的进程可以被同优先级的进程抢占，RR调度在同优先级的进程间引入时间片轮转机制。OTHER则是在所有不同优先级的进程间引入时间片轮转机制，所有优先级的进程根据优先级的高低进行分时运行，通过动态调整进程优先级使所有进程都有运行机会，在OTHER调度中就存在低优先级抢占高优先级进程（静态优先级）的情况。
从内核的角度看，实时进程优先级0-99，数值越小优先级越高，但在我们创建实时进程app，设置进程优先级的时候,发现，设置为99的进程优先级要高于98，就是说在实时进程app中优先级的高低是数值越大优先级越高。之所以会有这个问题，是因为app进程所调用的用来设置当前进程优先级的api函数内部有一个转换计算。
进程调度规则设定系统调用：sched_setscheduler (__pid_t __pid, int __policy,__const struct sched_param *__param)
系统调用根据pid参数设定指定进程调度规则和优先级级别，pid=0时设定调用该函数的进程。在__policy=SCHED_FIFO的情况下，最终调用函数normal_prio(structtask_struct *p)使用公式prio = MAX_RT_PRIO-1 - p->rt_priority计算出传递给内核的真是优先级，所以传入sched_setscheduler的优先级通过计算99对应0，0对应99，对内核而言优先级还是0最高，只是在app和内核之间加了一个转算过程。