首页 文章

哪个实时优先级是Linux中的最高优先级

提问于
浏览
56

在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(高)范围内 . ”

哪个是最高的实时优先级?

6 回答

  • 74

    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.
     */
    

    注意这部分:

    Priority values are inverted: lower p->prio value means higher priority .

  • 5

    要确定可以以编程方式设置的最高实时优先级,请使用sched_get_priority_max函数 .

    在Linux 2.6.32上,对sched_get_priority_max(SCHED_FIFO)的调用返回99 .

    http://linux.die.net/man/2/sched_get_priority_max

  • 9
    • 当然,实时优先级适用于RT策略FIFO和RR,其范围为0-99 .

    • 我们确实有40作为BATCH的非实时进程优先级的计数,其他策略从0-39而不是从100到139 . 这可以通过查看系统中的任何进程来观察实时过程 . 默认情况下它的PR为20,NIceness为0 . 如果你降低了一个过程的好处(通常,这个数字越低或越负越好,过程越穷),比如从0到-1,你会发现PRiority会从20降到19 . 这只是告诉你如果你让一个过程更加饥饿,或者想通过降低PID的漂亮度值来获得更多关注,那么你的优先级也会降低,从而降低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
    [admin@abc.com ~]# renice -n -11 2079
    2079: old priority -10, new priority -11
    [admin@abc.com ~]# top -b | grep mgmtd
    2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
    ^C
    

    希望这个实际例子能够澄清疑虑,并且可能有助于修复错误来源的词语,如果有的话 .

  • 1

    假设正常过程具有从100到139的静态优先级,这种假设最多是易变的,最坏的情况下是无效的 . 我的意思是:set_scheduler只允许sched_priority为0(表示动态优先级调度程序),SCHED_OTHER / SCHED_BATCH和SCHED_IDLE(从2.6.16开始为真) .

    程序化静态优先级仅为SCHED_RR和SCHED_FIFO的1-99

    现在,您可能会看到动态调度程序内部使用100-139的优先级,内核在内部管理动态优先级(包括翻转高优先级与低优先级的含义以使比较或排序更容易)的内容应该是不透明的到用户空间 .

    请记住,在SCHED_OTHER中,您主要是将进程填充到同一优先级队列中 .

    我们的想法是让内核更容易调试并避免愚蠢的越界错误 .

    因此,切换含义的基本原理可能是内核开发人员不想使用像139-idx这样的数学(只是在idx> 139的情况下)......最好用idx-100进行数学运算并颠倒概念因为idx <100是很好理解的低与高 .

    另外一个副作用是,好处变得更容易处理 . 100 - 100 <=>不错== 0; 101-100 <=> nice == 1;等等更容易 . 它也很好地折叠到负数(没有与静态优先级相关)99 - 100 <=> nice == -1 ...

  • 0

    Short Answer

    99将成为实时优先的赢家 .

    PR是优先级 . PR越低,该过程的优先级越高 .

    PR的计算方法如下:

    • 用于正常过程:PR = 20 - NI(NI很好,范围从-20到19)

    • 用于实时进程:PR = - 1 - real_time_priority(real_time_priority范围从1到99)

    Long Answer

    有两种类型的进程,正常进程和实时对于正常进程(仅适用于那些进程),nice应用如下:

    Nice

    “漂亮”标度从-20到19,而-20是最高优先级,19是最低优先级 . 优先级计算如下:

    PR = 20 + NI

    NI是最好的水平,PR是优先级 . 我们可以看到,-20实际上映射到0,而19映射到39 .

    默认情况下,程序nice值为0 bit,root用户可以使用以下命令为具有指定nice值的程序提供午餐:

    nice -n <nice_value> ./myProgram
    

    Real Time

    我们可以走得更远 . 优先级实际上用于用户程序 . UNIX / LINUX总体优先级的范围为140,而nice值使进程能够映射到范围的最后部分(从100到139) . 该等式使得从0到99的值不可达,这将对应于负PR级别(从-100到-1) . 为了能够访问这些值,该过程应该被称为“实时” .

    LINUX环境中有5个调度策略可以使用以下命令显示:

    chrt -m
    

    这将显示以下列表:

    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
    

    调度过程可以分为2组,正常调度策略(1到3)和实时调度策略(4和5) . 实时流程始终优先于正常流程 . 可以使用以下命令调用实时进程(示例是如何声明SCHED_RR策略):

    chrt --rr <priority between 1-99> ./myProgram
    

    要获得实时过程的PR值,应用以下等式:

    PR = -1 - rt_prior

    其中rt_prior对应于1到99之间的优先级 . 因此,具有比其他进程更高优先级的进程将是使用数字99调用的进程 .

    重要的是要注意,对于实时进程,不使用nice值 .

    要查看进程的当前“niceness”和PR值,可以执行以下命令:

    top
    

    其中显示以下输出:

    enter image description here

    在图中,显示PR和NI值 . 最好注意PR值-51对应于实时值的过程 . 还有一些进程的PR值表示为“rt” . 该值实际上对应于PR值-100 .

  • 0

    我做了一个实验来解决这个问题,如下:

    • process1:RT优先级= 40,CPU亲和性= CPU 0.此进程“旋转”10秒,因此不会让任何优先级较低的进程在CPU 0上运行 .

    • process2:RT优先级= 39,CPU亲和力= CPU 0.此过程每0.5秒向stdout输出一条消息,介于两者之间 . 它打印出每条消息的经过时间 .

    我正在使用PREEMPT_RT补丁运行2.6.33内核 .

    要运行实验,我在一个窗口(以root身份)运行process2,然后在另一个窗口中启动process1(以root身份) . 结果是process1似乎抢占了进程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()设置的实时优先级 .

相关问题