Негативы запущенных процессов с приоритетом в реальном времени?

Есть ли недостатки у запущенных процессов с приоритетом в реальном времени ( chrt -f 99)?

Моя гипотеза состоит в том, что это в сочетании со сродством гарантирует, что любое преимущество моего процесса будет минимальным, и, следовательно, любое дрожание (особенно задержка в сети) будет минимизировано - это не поможет с общей задержкой, но в этот момент я больше касается джиттера.

(Ядро: 2.6.16 / 3.0)

linux process real-time

— Nim
источник

Это выглядит полезным для вас: как уменьшить дрожание для Java?

— ire_and_curses

@ire_and_curses, в настоящее время процесс выполняется на собственном изолированном ядре (по крайней мере, в главном потоке обработки), однако прерывания не запланированы на том же ядре (это невозможно сделать, так как есть несколько похожих процессов, использующих один и тот же сетевой интерфейс). ), это скорее последнее усилие. Частота APIC интересна, я не сталкивался с этим раньше.

— Ним

Самым непосредственным недостатком запуска процесса в реальном времени является то, что этот процесс может легко заморозить любой другой процесс в системе. Результатом, с вашей точки зрения, будет то, что компьютер полностью не реагирует на клавиатуру, мышь и, возможно, сеть, пока процесс реального времени использует процессор. Это может произойти, если что-то пойдет не так, и процесс перейдет в бесконечный цикл, или даже временно, если процесс начнет длительные вычисления без периодического ожидания ввода. (Так, например, не запускайте SETI @ home с приоритетом в реальном времени.)

Одиночный однопоточный процесс на многоядерном процессоре с меньшей вероятностью вызовет эту проблему, поскольку существуют другие ядра, которые может использовать процесс с более низким приоритетом. Но если этот процесс создает какие-либо дочерние процессы, они наследуют один и тот же приоритет в реальном времени, поэтому все может выйти из-под контроля, если вы не будете осторожны.

У sched_setscheduler(2)man-страницы есть хороший совет:

Поскольку неблокирующий бесконечный цикл в процессе, запланированном в SCHED_FIFO или SCHED_RR, навсегда заблокирует все процессы с более низким приоритетом, разработчик программного обеспечения всегда должен держать на консоли доступную оболочку, запланированную с более высоким статическим приоритетом, чем у тестируемого приложения. Это позволит выполнить аварийное уничтожение протестированных приложений реального времени, которые не блокируются или не завершаются, как ожидалось. Смотрите также описание ограничения ресурса RLIMIT_RTTIME в getrlimit (2).

Это должна быть оболочка на консоли - не под Xterm, если только вы не хотите отдавать приоритет всему X в реальном времени.

— Jander
источник

Да - это главная проблема, с которой я сталкиваюсь. Если не считать код ядра, чтобы определить все процессы, которые должны иметь более высокий приоритет, единственный вариант - отодвинуть все остальные в сторону от моего процесса и затем переместить все, что требует какой-либо формы ввода-вывода, в другие ядра ... хммм. ..

— Ним