Какой приоритет в реальном времени является высшим приоритетом в Linux

Question

В диапазоне приоритетов процесса Linux в реальном времени от 1 до 99 мне непонятно, какой из них имеет самый высокий приоритет, 1 или 99.

Раздел 7.2.2 «Понимание ядра Linux» (O 'Рейли) говорит, что 1 является наивысшим приоритетом, что имеет смысл, учитывая, что нормальные процессы имеют статические приоритеты от 100 до 139, причем 100 является наивысшим приоритетом:

"Каждый процесс в реальном времени связан сприоритет в реальном времени, который представляет собой значение в диапазоне от 1 (самый высокий приоритет) до 99 (самый низкий приоритет). "

С другой стороны, справочная страница sched_setscheduler (RHEL 6.1) утверждает, что 99самое высокое:

"Процессы, запланированные в соответствии с одной из политик реального времени (SCHED_FIFO, SCHED_RR), имеют значение sched_priority в диапазоне от 1 (низкий) до 99 (высокий)."

Какой самый высокий приоритет в реальном времени?

Answer 1

Я провел эксперимент, чтобы зафиксировать это следующим образом:

• process1: приоритет RT = 40, сродство CPU = CPU 0. Этот процесс «вращается» в течение 10 секунд, поэтомуне позволяет любому процессу с более низким приоритетом работать на CPU 0.

• process2: приоритет RT = 39, сходство CPU = CPU 0. Этот процесс печатает сообщение в стандартный вывод каждые 0,5 секунды,спать междуОн выводит прошедшее время с каждым сообщением.

Я использую ядро ​​2.6.33 с патчем PREEMPT_RT.

Чтобы запустить эксперимент, я запускаю process2в одном окне (как root), а затем запустите process1 (как root) в другом окне.В результате process1, по-видимому, выгружает process2, не позволяя ему работать в течение полных 10 секунд.

Во втором эксперименте я меняю приоритет RT для process2 на 41. В этом случае process2 равен not вытесняется process1.

Этот эксперимент показывает, что значение приоритета больше RT в sched_setscheduler () имеет более высокий приоритет.Похоже, это противоречит тому, что Майкл Фукаракис указал на 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 ().

Answer 2

Этот комментарий в 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значение означает более высокий приоритет .

Answer 3

Чтобы определить самый высокий приоритет в реальном времени, который вы можете установить программно, используйте функцию 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

Answer 4

Короткий ответ

99 станет победителем за приоритет в реальном времени.

PR - уровень приоритета (диапазон от -100 до 40). Чем ниже PR, тем выше приоритет процесса.

PR рассчитывается следующим образом:

• для нормальных процессов: PR = 20 - NI (NI подходит и составляет от -20 до 19)
• для процессов реального времени: PR = - 1 - real_time_priority (real_time_priority варьируется от 1 до 99)

Длинный ответ

Существует 2 типа процессов: обычный и реальное время Для обычных (и только для тех), nice применяется следующим образом:

Nice

Шкала «добротности» варьируется от -20 до 19, тогда как -20 это самый высокий приоритет и 19 самый низкий приоритет. Уровень приоритета рассчитывается следующим образом:

PR = 20 + NI

Где NI - хороший уровень, а PR - уровень приоритета. Итак, как мы видим, -20 фактически отображается в 0, а 19 - в 39.

По умолчанию, значение nice программы равно 0 бит, и пользователь root может запускать программы с указанным значением nice с помощью следующей команды:

nice -n <nice_value> ./myProgram 

Реальное время

Мы могли бы пойти еще дальше. Хороший приоритет на самом деле используется для пользовательских программ. Тогда как общий приоритет 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 не используется.

Чтобы увидеть текущую «привлекательность» и значение PR процесса, можно выполнить следующую команду:

top

Который показывает следующий вывод:

На рисунке показаны значения PR и NI. Хорошо отметить процесс со значением PR -51, которое соответствует значению в реальном времени. Есть также некоторые процессы, чье значение PR указано как «rt». Это значение фактически соответствует значению PR -100.

Answer 5

1. Абсолютно, приоритет в реальном времени применим к политикам RT FIFO и RR, который варьируется от 0 до 99.

2. У нас есть 40 как счетчик приоритета процесса не в реальном времени для пакетов, ДРУГИХ политик, который варьируется от 0 до 39, а не от 100 до 139. Это можно наблюдать, просматривая любой процесс в система, которая не является процессом в реальном времени. По умолчанию он будет содержать PR 20 и NIceness 0. Если вы уменьшите точность процесса (как правило, уменьшите или уменьшите число, уменьшив степень сложности процесса), скажем, с 0 до -1, вы увидите, что приоритет снизится до 20 с 20. Это просто говорит о том, что если вы сделаете процесс более голодным или хотели бы получить немного больше внимания, уменьшив значение 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
   

Надеюсь, этот практический пример прояснит сомнения и может помочь исправить слова в неверном источнике, если таковые имеются.

Answer 6

Ваше предположение, что нормальные процессы имеют статические приоритеты от 100 до 139, в лучшем случае изменчиво, а в худшем - неверно.Я имею в виду, что: set_scheduler позволяет только sched_priority быть 0 (что указывает на динамический приоритетный планировщик) с SCHED_OTHER / SCHED_BATCH и SCHED_IDLE (true по состоянию на 2.6.16).

Программно статические приоритеты только 1-99для SCHED_RR и SCHED_FIFO

Теперь вы можете увидеть, как приоритеты 100-139 используются внутренне динамическим планировщиком, однако, что ядро ​​делает внутри для управления динамическими приоритетами (в том числе переключение значения высокий или низкий приоритет насделать сравнение или сортировку проще) должен быть непрозрачным для пользовательского пространства.

Помните, что в SCHED_OTHER вы в основном помещаете процессы в одну и ту же очередь приоритетов.

Идея состоит в том, чтобы упростить отладку ядра и избежать глупых ошибок.

Таким образом, обоснование переключения смысла может заключаться в том, что разработчик ядра не хочет использовать математику, например 139-idx (на всякий случай idx> 139) ... лучше делать математику с idx-100 и полностью изменить концепцию низкого против высокого, потому что idx <100 хорошо понято.</p>

Также побочным эффектом является то, что с милостью становится легче иметь дело.100 - 100 <=> приятно == 0;101-100 <=> приятно == 1;и т.д. проще.Он также хорошо разворачивается до отрицательных чисел (НИЧЕГО не делать со статическими приоритетами) 99 - 100 <=> nice == -1 ...