Подтвердить что ты не робот

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

В диапазоне приоритетов процесса Linux в режиме реального времени от 1 до 99 мне неясно, что является наивысшим приоритетом 1 или 99.

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Во втором эксперименте я меняю приоритет process2 RT на 41. В этом случае process2 не выгружается процессом1.

Этот эксперимент показывает, что большее значение приоритета 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().

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

Ответ 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

Ответ 4

Ваше предположение о том, что обычные процессы имеют статические приоритеты от 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 и отмените концепцию low vs. high, так как idx < 100 хорошо понятны.

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

Ответ 5

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

  • У нас есть 40 как счет приоритета процесса в режиме реального времени для BATCH, OTHER, которые варьируются от 0-39, а не от 100 до 139. Это можно наблюдать, просматривая любой процесс в системы, которая не является процессом в реальном времени. По умолчанию он будет иметь PR 20 и NIceness 0. Если вы снижаете тонкость процесса (обычно, более низкое или отрицательное число меньше, чем тонкость, более голодный процесс), скажем, от 0 до -1, вы заметите, что коэффициент приоритета снизится до 19 с 20. Это просто говорит о том, что если вы сделаете процесс более голодным или хотите получить немного больше внимания, уменьшив значение симметрии PID, вы также получите снижение приоритета, тем самым снимите ПРИОРИТЕТНЫЙ номер ВЫШЕ ПРИОРИТЕТ.

    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
[[email protected] ~]# renice -n -11 2079
2079: old priority -10, new priority -11
[[email protected] ~]# top -b | grep mgmtd
2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
^C

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