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

Чи є недоліки запущених процесів з пріоритетом у режимі реального часу ( chrt -f 99)?

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

(Ядро: 2.6.16 / 3.0)

linux process real-time

— Нім
джерело

Це виглядає для вас корисно: Як зменшити тремтіння для Java?

— ire_and_curses

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

— Нім

Найбільш безпосереднім недоліком запуску процесу в режимі реального часу є те, що цей процес може легко голодувати за всі інші процеси в системі. Результатом з вашої точки зору буде те, що комп'ютер абсолютно не реагує на клавіатуру, мишу та, ймовірно, мережу, настільки, доки в режимі реального часу використовується процесор. Це може статися, якщо щось піде не так, і процес переходить у нескінченний цикл, або навіть тимчасово, якщо процес починає тривалий розрахунок, не чекаючи періодично введення. (Так, наприклад, не запускайте SETI @ home з пріоритетом у режимі реального часу.)

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

Сторінка sched_setscheduler(2)чоловіка має хороші поради:

Оскільки неблокуючий нескінченний цикл у процесі, запланованому за SCHED_FIFO або SCHED_RR, назавжди блокуватиме всі процеси з нижчим пріоритетом, розробник програмного забезпечення повинен завжди тримати доступну на консолі оболонку, заплановану за вищим статичним пріоритетом, ніж тестована програма. Це дозволить екстрено знищити перевірені додатки в режимі реального часу, які не блокують і не припиняють, як очікувалося. Див. Також опис обмеження ресурсів RLIMIT_RTTIME в getrlimit (2).

Це має бути оболонка на консолі - не під Xterm, якщо ви не хочете також надати всім пріоритетам X в реальному часі.

— Джандер
джерело

Так - це головна проблема, з якою я стикаюся. Не маючи ознайомлення з кодом ядра, щоб визначити всі процеси, які повинні мати більш високий пріоритет, єдиний варіант - голодувати всі інші вбік від мого процесу, а потім перемістити все, що вимагає будь-якої форми io, до інших ядер ... хммм. ..

— Нім