Negativi di esecuzione dei processi con priorità in tempo reale?

Ci sono aspetti negativi dei processi in esecuzione con priorità in tempo reale ( chrt -f 99)?

La mia ipotesi è che questo combinato con un'affinità assicurerà che qualsiasi prelazione del mio processo sia minima e quindi qualsiasi jitter (in particolare la latenza di rete) sarà minimizzato - questo non aiuterà con la latenza generale, ma in questo momento sono più preoccupato per il jitter.

(Kernel: 2.6.16 / 3.0)

linux process real-time

— Nim
fonte

Ti sembra utile: come ridurre il jitter per Java?

— ire_and_curses,

@ire_and_curses, attualmente il processo viene eseguito sul proprio core isolato (almeno il thread di elaborazione principale), tuttavia gli interrupt non sono programmati sullo stesso core (non è possibile farlo poiché ci sono molti processi simili che si basano sulla stessa interfaccia di rete ), questo è più di un ultimo sforzo. La frequenza APIC è interessante, non l'ho mai vista prima.

— Nim,

Il rovescio della medaglia più immediato dell'esecuzione di un processo in tempo reale è che il processo può facilmente morire di fame ogni altro processo sul sistema. Il risultato dal tuo punto di vista sarà che il computer non risponde completamente alla tastiera, al mouse e probabilmente alla rete, fintanto che il processo in tempo reale utilizza la CPU. Questo può accadere se qualcosa va storto e il processo passa in un ciclo infinito, o anche temporaneamente se il processo avvia un calcolo di lunga durata senza attendere l'input periodico. (Ad esempio, non eseguire SETI @ home con priorità in tempo reale.)

Un processo a thread singolo su una CPU multi-core ha meno probabilità di causare questo problema poiché esistono altri core che il processo con priorità inferiore può utilizzare. Ma se quel processo crea processi secondari, erediteranno la stessa priorità in tempo reale, quindi le cose possono sfuggire al controllo se non stai attento.

La sched_setscheduler(2)pagina man contiene buoni consigli:

Poiché un loop infinito senza blocco in un processo pianificato sotto SCHED_FIFO o SCHED_RR bloccherà per sempre tutti i processi con priorità inferiore, uno sviluppatore software dovrebbe sempre tenere disponibile sulla console una shell pianificata con una priorità statica superiore rispetto all'applicazione testata. Ciò consentirà l'uccisione di emergenza di applicazioni testate in tempo reale che non si bloccano o terminano come previsto. Vedi anche la descrizione del limite di risorse RLIMIT_RTTIME in getrlimit (2).

Dovrebbe essere una shell sulla console , non sotto un Xterm, a meno che tu non voglia dare anche a X tutta la priorità in tempo reale.

— Jander
fonte

Sì, questo è il problema principale che mi sembra di incontrare. A corto di leggere il codice del kernel per determinare tutti i processi che devono avere una priorità più elevata, l'unica opzione è quella di far morire di fame tutti gli altri a parte il mio processo e quindi spostare tutto ciò che richiede qualsiasi forma di io su altri core ... hmmm. ..

— Nim,