Я использую pthread в Linux. Я хотел бы увеличить приоритет потока, установив параметры sched_param.priority. Однако я не мог найти много информации из сети относительно диапазона приоритета потока, который я мог бы установить, или об описании приоритета потока.
Кроме того, я хотел бы узнать об относительном приоритете потока, поскольку я бы не хотел, чтобы приоритет потока был слишком высоким и в результате остановилась ОС. Может ли кто-нибудь помочь мне с этим?
Политикой планирования 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.
Предупреждение: неправильное использование политик планирования в реальном времени может повредить вашу систему. Для этого вам нужны привилегии 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. Для точности!:)
POSIX определяет запрос, поэтому вы можете задать OS для допустимого диапазона приоритетов.
int sched_get_priority_max(int policy);
int sched_get_priority_min(int policy);
Не ожидайте повышенного приоритета, чтобы задушить устройство. На самом деле, не ожидайте, что он что-нибудь сделает, если вы уже не используете 100% циклов процессора. Не удивляйтесь, если в запросе указывается, что приоритет не выше, чем значение по умолчанию.
Текущий ответ от levif (рекомендующий SCHED_BATCH) неверен для текущей реализации потока NPTL в Linux (вы можете проверить, какая реализация имеет ваше ядро, запустив "getconf GNU_LIBPTHREAD_VERSION" ).
В сегодняшнем ядре только политики планирования в реальном времени позволяют устанавливать sched_priority - он всегда равен 0 для политик non-RT (SCHED_OTHER, SCHED_BATCH и SCHED_IDLE). Ваш единственный выбор для политик, отличных от RT, - это установить "хорошие" значения, например. по setpriority(). Не существует хороших характеристик точного поведения, которые можно ожидать, установив "хороший", но, по крайней мере, теоретически это может варьироваться от версии ядра до версии ядра. Для нынешних ядер 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 говорится, что "хороший" влияет на процессы, а не на отдельные потоки. Хорошей новостью является то, что реализации потоков Linux (как NPTL, так и исходные потоки Linux) нарушают спецификацию и позволяют влиять на отдельные потоки. Мне показалось забавным, что это часто вызывается в разделе "ОШИБКИ" на страницах руководства. Я бы сказал, что ошибка была в спецификации POSIX.1, которая должна была допускать такое поведение, а не в реализациях, которые были вынуждены предоставить его, несмотря на спецификацию, и делали это сознательно и намеренно. Другими словами - не ошибка.
Большая часть этой информации подробно описана на странице расписания (7) (которая по какой-то причине не поставляется в моей системе Fedora 20): http://man7.org/linux/man-pages/man7/sched.7.html
Если вы действительно хотите повлиять на sched_priority, вы можете посмотреть политики реального времени, такие как SCHED_RR).