it-swarm.com.ru

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

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

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

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

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

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

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

59
David Steinhauer

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

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

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

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

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

Во втором эксперименте я меняю приоритет _2RT для process2 на 41. В этом случае process2 не вытесняется 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 ().

78
David Steinhauer

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

9
Michael Foukarakis

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

5
Pawel

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

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 

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

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

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

enter image description here

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

4
Agustin Barrachina
  1. Абсолютно, приоритет реального времени применим к RT политикам FIFO и ​​RR, который варьируется от 0 до 99.
  2. У нас есть 40 как счетчик приоритета процесса не в реальном времени для BATCH, ДРУГИЕ политики, которые варьируются от 0 до 39, а не от 100 до 139. Это можно увидеть, посмотрев на любой процесс в системе, который не является в реальном времени процесс. По умолчанию он будет содержать PR 20 и NIceness 0. Если вы уменьшите точность процесса (как правило, уменьшите или уменьшите число, уменьшив степень сложности процесса), скажем, с 0 до -1, вы увидите, что приоритет снизится до 20. С 20. Это просто говорит что если вы сделаете процесс более голодным или захотите получить немного больше внимания, уменьшив значение PID, то вы также получите снижение приоритета, тем самым уменьшив число PRIORITY выше HIGHER 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
    [[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
    

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

0
Sturdyone

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

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

0
Ahmed Masud