Negatywy dotyczące uruchamiania procesów z priorytetem w czasie rzeczywistym?

Czy są jakieś wady uruchamiania procesów z priorytetem w czasie rzeczywistym ( chrt -f 99)?

Moja hipoteza jest taka, że w połączeniu z powinowactwem zapewni, że wszelkie uprzedzenia mojego procesu będą minimalne, a zatem wszelkie jitter (szczególnie opóźnienie sieci) zostanie zminimalizowane - nie pomoże to w całkowitym opóźnieniu, ale w tej chwili jestem bardziej dotyczy jittera.

(Jądro: 2.6.16 / 3.0)

linux process real-time

— Nim
źródło

To wydaje się pomocne: jak zmniejszyć jitter dla Java?

— ire_and_curses

@ire_and_curses, obecnie proces działa na własnym izolowanym rdzeniu (przynajmniej głównym wątku przetwarzania), jednak przerwania nie są zaplanowane na tym samym rdzeniu (nie można tego zrobić, ponieważ istnieje kilka podobnych procesów opartych na tym samym interfejsie sieciowym ), to jest ostatni wysiłek. Częstotliwość APIC jest interesująca, nie spotkałem się z tym wcześniej.

— Nim,

Najbardziej bezpośrednim minusem uruchamiania procesu w czasie rzeczywistym jest to, że proces ten może z łatwością zagłodzić każdy inny proces w systemie. Z twojego punktu widzenia wynik będzie taki, że komputer całkowicie nie będzie reagował na klawiaturę, mysz i prawdopodobnie sieć, dopóki proces procesora używa procesora w czasie rzeczywistym. Może się to zdarzyć, jeśli coś pójdzie nie tak i proces przejdzie w nieskończoną pętlę, lub nawet tymczasowo, jeśli proces rozpocznie długotrwałe obliczenia bez okresowego oczekiwania na dane wejściowe. (Na przykład nie uruchamiaj SETI @ home z priorytetem w czasie rzeczywistym).

Sam proces jednowątkowy na wielordzeniowym procesorze jest mniej prawdopodobny, aby powodować ten problem, ponieważ istnieją inne rdzenie, które mogą wykorzystywać proces o niższym priorytecie. Ale jeśli proces ten utworzy jakiekolwiek procesy potomne, odziedziczą ten sam priorytet w czasie rzeczywistym, więc rzeczy mogą wymknąć się spod kontroli, jeśli nie będziesz ostrożny.

Strona sched_setscheduler(2)podręcznika ma dobrą radę:

Ponieważ nieblokująca się nieskończona pętla w procesie zaplanowanym w SCHED_FIFO lub SCHED_RR na zawsze zablokuje wszystkie procesy o niższym priorytecie, programista powinien zawsze przechowywać w konsoli powłokę zaplanowaną z wyższym priorytetem statycznym niż testowana aplikacja. Umożliwi to awaryjne zabicie testowanych aplikacji w czasie rzeczywistym, które nie blokują się ani nie kończą zgodnie z oczekiwaniami. Zobacz także opis limitu zasobów RLIMIT_RTTIME w getrlimit (2).

To powinna być powłoka na konsoli - nie pod Xterm, chyba że chcesz nadać wszystkim X także priorytet w czasie rzeczywistym.

— Jander
źródło

Tak - wydaje mi się, że to główny problem. Poza czytaniem kodu jądra w celu ustalenia wszystkich procesów, które muszą mieć wyższy priorytet, jedyną opcją jest głodzenie wszystkich innych poza moim procesem, a następnie przeniesienie wszystkiego, co wymaga dowolnej formy io, do innych rdzeni ... hmmm. ..

— Nim,