Так. Чем больше я читаю про гарантии «реального времени» в планировщике ядра, тем меньше понимаю.
Вот у нас есть настройка
/proc/sys/kernel/sched_rt_runtime_us. Если я правильно понимаю, она задаёт количество микросекунд, на которое приложения реального времени могут занять процессор в один период планирования (или -1, если мы разрешаем им занять
всё время). Так как период планирования равен одной секунде:
$ cat /proc/sys/kernel/sched_rt_period_us
1000000а в
/proc/sys/kernel/sched_rt_runtime_us по умолчанию число 950000, каждую секунду задачи реального времени могут занять 0,95 с.
Дальше приложения могут с помощью
системного вызова sched_setscheduler задавать себе приоритет, в том числе приоритет реального времени — числом от 1 до 99, которое означает долю времени ЦП, гарантируемого приложению.
Я (очень бегло) посмотрел исходники, похоже, в JACK именно это и происходит.
Здесь, насколько я понимаю, POSIX-версия реализации тредов в JACK пытается получить приоритет реального времени с помощью вызова функции
pthread_setschedparam():
https://github.com/jackaudio/jack2/blob/0ee218826b299a95f937b7c88f10af56534d6cbd/posix/JackPosixThread.cpp#L244Здесь pthreads зовут функцию
__sched_setscheduler() из glibc:
https://code.woboq.org/userspace/glibc/nptl/pthread_setschedparam.c.html#56Реализацию этого дела в glibc для Linux я сходу не нашёл (
здесь только заглушка, а как подставляется реализация для конкретной платформы, я не понимаю), но нет оснований полагать, что там что-то кроме системного вызова
sched_setscheduler.
Пока всё понятно. Довольно логичная и простая система.
Но! Дальше на сцене появляются опция
CONFIG_RT_GROUP_SCHED, Леннарт Поттеринг и cgroups — и всё безнадёжно запутывается.
Эта опция включена в стандартном альтовом ядре:
sudo cat /boot/config-5.4.31-std-def-alt1 | grep CONFIG_RT_GROUP_SCHED
CONFIG_RT_GROUP_SCHED=yЕсли она включена, запуск приложений реального времени от непривилегированного пользователя становится невозможен, пока они не включены в некую группу, которой выделены ресурсы ЦП:
By default all bandwidth is assigned to the root group and new groups get the
period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
want to assign bandwidth to another group, reduce the root group's bandwidth
and assign some or all of the difference to another group.
Realtime group scheduling means you have to assign a portion of total CPU
bandwidth to the group before it will accept realtime tasks. Therefore you will
not be able to run realtime tasks as any user other than root until you have
done that, even if the user has the rights to run processes with realtime
priority!
В апреле 2008 Леннарт просит включить
CONFIG_RT_GROUP_SCHED в ядре Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=442959 в надежде, что PulseAudio от этого станет работать лучше (уже смешно).
Но! В июне 2015 всё тот же Леннарт
просит выключить CONFIG_RT_GROUP_SCHED в ядре Fedora!
И вот теперь у меня вопросы.
- Зачем в std-def включена опция CONFIG_RT_GROUP_SCHED?
- Как включивший эту опцию человек предлагает запускать от непривилегированного пользователя приложения, нуждающиеся в режиме реального времени (например, jackd)?
- Можно ли, не меняя конфиг ядра std-def, сделать jackd работоспособным «из коробки»?
Люди, принимающие такие решения, вообще заглядывают на этот форум?
