Scheduling Real Time Come?

[parisisalvo]

Salve
sto realizzando un'applicazione tempo critica.
So che ho diverse opzioni :
1) patch per il kernel
2) installare RTAI (kernel RealTime)
3) lasciare tutto com'e' e provare a giocare con sched.h e pthread.h

faccio partire il processo, dal processo partono diversi thread (nessun figlio)
ai thread ho dato priorita' alta con pthread_attr_setschedparam
se tramite le funzioni della lib sched.h do altissima priorita' al processo ne guadagneranno anke i thread da lui creati?
Dato che se non ne guadagnano i thread (che sn il cuore del programma) nn ho ragione di schedulare con prio piu' alta il quasi inutile "main".
Grazie
Salvo

[ilsensine]

Originariamente inviato da parisisalvo

Salve
sto realizzando un'applicazione tempo critica.
So che ho diverse opzioni :
1) patch per il kernel
2) installare RTAI (kernel RealTime)

Puoi provare con le patch di Montavista per la low latency/RT. Sembrano promettenti e già si parla di una futura inclusione.

3) lasciare tutto com'e' e provare a giocare con sched.h e pthread.h
faccio partire il processo, dal processo partono diversi thread (nessun figlio)
ai thread ho dato priorita' alta con pthread_attr_setschedparam

Sicuramente da provare, probabilmente uno scheduling FIFO o Round Robin è sufficiente per la maggior parte delle operazioni RT (v. pthread_attr_setschedpolicy)
Potrebbe anche essere consigliabile un mlockall() all'inizio del programma (thread principale).

se tramite le funzioni della lib sched.h do altissima priorita' al processo ne guadagneranno anke i thread da lui creati?

Non so sinceramente se lo scheduler è ereditato (mi sembvra di sì), però quando ci sono di mezzo i thread userei le funzioni apposite.

Occhio che il RT richiede cooperazione da parte del programmatore: fai un thread RT ad alta priorità rispetto agli altri, che sfora la sua quota temporale, e tutto è inutile.

Sposto in programmzione.

[parisisalvo]

Bene, onestamente spero che la schedulazione "semplice" funzioni...oggi facevo esperimenti.
Se in un thread faccio getpid, mi torna il pid del main (processo principale) e infatti eredità la sched...pero' se dentro il thread tento di manipolare la schedulazione, il valore cambia, ma il S.O. nn ne risente...
mi spiego meglio
nel thread faccio uno setsched FIFO + 99, se faccio un getsched mi da 99 pero' li thread nn viene schedulato da 99 (quando schedulo a 99 con un while da un miliardo di cicli mi si blocca pure il mouse) se invece schedulo nel main tutto bene.
il mio software ha 4/5thread+main.
Uno che "guarda" la scheda sonora per vedere se ci sono impulsi superiore a una certa soglia in dB
uno che "guarda" la scheda di rete tramite socket per vedere se ci sn pacchetti in arrivo e che a sua volta lancia un altro thread per vedere di che tipo di pacchetto si tratta.
uno che manda i pacchetti ogni tot secondi (10 circa)
uno che ogni 30 pacchetti applica un algoritmo per computare dei ritardi.
Per nn perdere il vantaggio dovrei schedulare tutti e 5 a 99, giusto?
Cosa è un mlockall() ? cosa implica?
grazie mille
Salvo

[ilsensine]

Originariamente inviato da parisisalvo

Bene, onestamente spero che la schedulazione "semplice" funzioni...oggi facevo esperimenti.
Se in un thread faccio getpid, mi torna il pid del main (processo principale) e infatti eredità la sched...

Eh no attenzione, sui kernel 2.6 con le tls per strani scherzi del destino la getpid() ritorna il kernel TID, mentre la gettid ritorna...il kernel PID!
In soldoni: se devi chiamare delle funzioni che richiedono il pid di processo da dentro un thread (ad es. sched_setscheduler), non usare la getpid ma la gettid (oppure usa le funzioni specifiche per i thread, come pthread_setscheduler).

pero' se dentro il thread tento di manipolare la schedulazione, il valore cambia, ma il S.O. nn ne risente...
mi spiego meglio
nel thread faccio uno setsched FIFO + 99, se faccio un getsched mi da 99 pero' li thread nn viene schedulato da 99 (quando schedulo a 99 con un while da un miliardo di cicli mi si blocca pure il mouse)

...quindi mi sembra schedulato RT. Un thread RT cpu-hog ti blocca tutta la macchina.

Per nn perdere il vantaggio dovrei schedulare tutti e 5 a 99, giusto?

Non necessariamente: uno scheduler RT (FIFO o RR) ha _sempre_ la precedenza sullo scheduler normale (quindi sugli altri processi). La prioroità statica RT ha senso se vuoi stabilire priorità diverse tra i vari thread RT. Quindi se imposti tutti a 99 hai lo stesso effetto che avresti impostandoli tutti...a 1!

Cosa è un mlockall() ? cosa implica?

man mlockall
Forza tutta la memoria del processo a risiedere in ram, eliminando i page fault e le attese di swapin/page load che cozzano per ovvi motivi con i requisiti real time.

[parisisalvo]

Originariamente inviato da ilsensine

Non necessariamente: uno scheduler RT (FIFO o RR) ha _sempre_ la precedenza sullo scheduler normale (quindi sugli altri processi). La prioroità statica RT ha senso se vuoi stabilire priorità diverse tra i vari thread RT. Quindi se imposti tutti a 99 hai lo stesso effetto che avresti impostandoli tutti...a 1!
.

ma rispetto agli altri processi kernel, non ottengo vantaggi? questi 5 tra loro si equivarrano, ma rispetto agli altri processi avranno la meglio??

Ora capisco la storia del PID non PID...quindi devo fare gettid (qual è il comando da consolle per vedere tutti i processi e thread?) cmq usero' le funzioni apposite per i thread.

[ilsensine]

Originariamente inviato da parisisalvo

ma rispetto agli altri processi kernel, non ottengo vantaggi? questi 5 tra loro si equivarrano, ma rispetto agli altri processi avranno la meglio??

Non mi sembra che i kernel threa girino con scheduling RT; dovrebbero usare lo scheduler normale con priorità alta (normalmente nice -10). Possono esserci eccezioni ovviamente.
Le isr (interrupt service routine) hanno la priorità maggiore, in quanto un irq hardware deve essere gestito immediatamente, ma non hanno contesto di processo quindi non le vedi negli elenchi dei task (i normali kernel thread li vedi; sono riconoscibili per l'assenza della VMA). Una isr mal scritta, oppure un blocco che tiene uno spinlock per troppo tempo, sono le principali sorgenti di alte latenze.

Ora capisco la storia del PID non PID...quindi devo fare gettid (qual è il comando da consolle per vedere tutti i processi e thread?) cmq usero' le funzioni apposite per i thread.

Visualizzi i processi tramite top oppure ps aux. I pid dei vari thread li trovi dentro /proc/<pid>/task/, dove <pid> è il pid riportato da top/ps (ovvero...il tid )

[parisisalvo]

Salve, rileggevo questo mio vechio post...
mi chiedevo una cosa...
date due istruzioni

istruzione1;
istruzione2;

si puo' dire allo scheduler in maniera diretta che alla fine dell'istruzione1 deve assolutamente essere eseguita l'istruzione2??

in pratica io assegno priorita' "bestiale" al thread che ha queste due istruzioni quindi mi aspetto che vengano eseguite insieme...nn c'e' un metodo "esplicito" ?

[ilsensine]

Scheduling FIFO o Round Robin, come ho detto. Nota che non c'è modo per impedire a un isr di interrompere il tuo processo, ma puoi evitare lo scheduling verso altri task.