Как увеличить приоритет потока в pthreads?

Question

Я использую pthread в Linux. Я хотел бы увеличить приоритет потока, установив параметры sched_param.priority. Однако я не смог найти много информации из сети относительно диапазона приоритета потока, который я мог установить, или об описании приоритета потока.

Кроме того, я хотел бы знать об относительном приоритете потока, поскольку я не хотел бы устанавливать приоритет потока слишком высоким и приводить к остановке ОС. Может ли кто-нибудь помочь мне с этим?

Answer 1

Политика планирования Linux по умолчанию - SCHED_OTHER, у которой нет выбора приоритета, но есть уровень nice для настройки внутри политики.

Вам придется перейти на другую политику планирования с использованием функции pthread_setschedparam (см. Также man sched_setscheduler)

«Обычные» политики планирования: (с sched_setscheduler(2))

   SCHED_OTHER   the standard round-robin time-sharing policy;
   SCHED_BATCH   for "batch" style execution of processes; and
   SCHED_IDLE    for running very low priority background jobs.

Политики планирования в реальном времени:

   SCHED_FIFO    a first-in, first-out policy; and
   SCHED_RR      a round-robin policy.

В вашем случае, возможно, вы можете использовать SCHED_BATCH, поскольку для этого не требуются привилегии root.

Предупреждение: неправильное использование политик планирования в реальном времени может привести к зависанию вашей системы,Вот почему вам нужны права суперпользователя для выполнения этой операции.

Чтобы быть уверенным в том, на что способна ваша машина, вы можете использовать инструмент chrt из пакета util-linux.В качестве примера:

$ chrt -m 
SCHED_OTHER min/max priority    : 0/0
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_BATCH min/max priority    : 0/0
SCHED_IDLE min/max priority     : 0/0

Способ тратить меньше времени (которое я часто использую):

alias batchmake='time chrt --batch 0 make --silent'

Во время пребывания с привилегиями пользователя это продвигаетmake на 15% (в моем случае).

Редактировать: представляет nice, SCHED_BATCH, SCHED_IDLE и chrt инструмент.Для точности!:)

Answer 2

Текущий ответ от levif (рекомендует SCHED_BATCH) неверен для текущей реализации потока NPTL в Linux (вы можете проверить, какая реализация у вашего ядра, запустив 'getconf GNU_LIBPTHREAD_VERSION').

В сегодняшнем ядре только политики планирования в реальном времени допускают настройку sched_priority - для политик, не относящихся к RT, это всегда 0 (SCHED_OTHER, SCHED_BATCH и SCHED_IDLE). Ваш единственный выбор для политик без RT - установить «хорошие» значения, например, по setpriority (). Тем не менее, нет хороших спецификаций точного поведения, которые можно ожидать, устанавливая «nice», и, по крайней мере, теоретически оно может варьироваться от версии ядра к версии ядра. В современных ядрах Linux «хороший» эффект очень похож на приоритет, поэтому вы можете использовать его почти взаимозаменяемо. Чтобы увеличить частоту планирования вашей темы, вы хотите понизить ваше значение 'nice'. Для этого требуется возможность CAP_SYS_NICE (обычно root, но не обязательно, см. http://man7.org/linux/man-pages/man7/capabilities.7.html и http://man7.org/linux/man-pages/man3/cap_set_proc.3.html).

Фактически SCHED_BATCH разработан для случая , противоположного тому, что запрашивал спрашивающий: он предназначен для длительных работ с интенсивным использованием процессора, которые могут жить с более низким приоритетом . Он говорит планировщику слегка оштрафовать приоритет пробуждения для потоков.

Также, чтобы ответить на один из предыдущих комментариев (у меня пока нет достаточной репутации, чтобы комментировать в ответ - некоторые отклики на этот ответ помогут :)). Да, плохая новость заключается в том, что спецификация POSIX.1 говорит, что «nice» влияет на процессы, а не на отдельные потоки. Хорошей новостью является то, что реализации потоков Linux (как NPTL, так и оригинальные потоки Linux) нарушают спецификацию и позволяют ей влиять на отдельные потоки. Я нахожу забавным, что это часто вызывается в разделе «ОШИБКИ» на страницах руководства. Я бы сказал, что ошибка была в спецификации POSIX.1, которая должна была допускать такое поведение, а не в реализациях, которые были вынуждены предоставлять ее, несмотря на спецификацию, и делали это сознательно и преднамеренно. Другими словами - не ошибка.

Большая часть этого подробно описана на справочной странице sched (7) (которая по некоторым причинам не поставляется в моей системе Fedora 20): http://man7.org/linux/man-pages/man7/sched.7.html

Если вы действительно хотите повлиять на sched_priority, вы можете посмотреть на политики в реальном времени, такие как SCHED_RR).

Answer 3

POSIX определяет запрос, поэтому вы можете запросить у OS действительный диапазон приоритетов.Не ожидайте, что повышенный приоритет захлебнется машиной.На самом деле, не ожидайте, что это что-то сделает, если вы уже не используете 100% циклов ЦП.Не удивляйтесь, если запрос скажет вам, что нет приоритета выше, чем по умолчанию.