Linux i Temps Real Alexei Lebedev

Què és un S.O. de Temps Real? Un sistema de Temps Real (Realtime) assegura que el temps de resposta serà inferior a un temps fixat segons les necessitats de l’aplicació. El temps de resposta normalment es refereix a l’interval que hi ha entre un esdeveniment (interrupció...) fins que aquest és atès. També s’anomena latència.

Què aporta? Capacitat per atendre serveis que fins fa ben poc requerien hardware especialitzat. Un sistema de computació convencional amb capacitats de temps real (PC + S.O. Temps Real, ...) és relativament molt barat, i és molt més flexible que un sistema especialitzat. Aplicacions Multimèdia, so video, és senzill muntar un estudi semi-professional amb un pressupost baix. Un efecte secundari (positiu) és que les interfícies gràfiques poden ser més agradables (resposta més ràpida).

Tipus de Temps Real Hard Realtime: El sistema ha de complir sempre les latències fixades, sinó els efectes poden ser desastrosos, com per exemple en centrals nuclears, llançament de satèl.lits, control aèri, etc... Soft Realtime: El sistema hauria de respondre sempre en el plaç previst, però si no ho aconsegueix l’únic efecte és una degradació del servei. Alguns exemples són les aplicacions d’àudio i vídeo.

Com mesurar-ho? És obvi que la latència no serà constant en un sistema, i depèn de molts factors, com la càrrega de la CPU, la utilització dels busos, les interrupcions a atendre, el tipus de programes... Dos indicadors que s’utilitzen són la latència mitjana i la pitjor. Normalment interessa tenir una latència mitjana el més baixa possible, però en un sistema amb hard realtime una lat. mitjana baixa no compensarà un cas pitjor massa alt.

Linux, és un S.O. de Temps Real? Les latències en un sistema Linux convencional en un PC actual poden arribar en algun cas a ser de més de 300 ms, tot i que és molt poc freqüent. En una aplicació d’àudio, en un sistema actual amb no massa càrrega, les elevades latències poden arribar a sobrepassar el llindar de l’audició humana, fent-lo perceptible (i molt molest). Sembla que el S.O. Linux estàndard no és gaire adequat per aplicacions de Temps Real.

Doncs... Per què fer un seminari sobre Linux? En altres S.O. sobretot comercials en aquest cas no tindríem cap més alternativa que buscar-ne un altre. Però Linux és diferent, documentació i codi font disponibles i molta gent disposada a treballar-hi. És força complicat fer els canvis necessaris al Kernel un mateix. Ja existeixen diverses solucions per resoldre el problema.

Per què Linux es comporta així? El planificador de processos està orientat a optimitzar el Throughput, no les latències. Es dóna prioritat al rendiment, i es deixa en segon terme la velocitat de resposta del sistema. Memòria virtual. Si una pàgina no és a la memòria física, s’ha d’anar a disc a buscar-la, amb la conseqüent pèrdua de temps.

Per què Linux es comporta així? Moltes estructures del kernel estan bloquejades per exclució mútua durant molt temps, de manera que el processos de T.R. s’han d’esperar a que s’alliberin. El planificador és “just”, i pot arribar a donar temps de CPU als processos de més baixa prioritat fins i tot quan hi ha un procés de T.R. esperant-se. Les cues per accedir al recursos hardware poden no ser FIFO, sinó que intenta optimitzar els temps d’accés (moure els capçals del disc dur, etc). Això pot perjudicar un procés de T.R. encara que hagi estat el primer a accedir-hi.

Per què Linux es comporta així? El sistema no s’apropiarà de la CPU quan està executant una crida al sistema. Fins i tot quan el procés de més baixa prioritat estigui al mig d’un fork, tots els altres processos i esdeveniments s’hauran d’esperar que acabi. Hi ha recursos de sistema limitats, com per exemple buffers, i si no n’hi ha de disponibles, qualsevol procés que en necessiti un s’haurà d’esperar.

Una possible solució... Linux ja suporta un conjunt d’especificacions POSIX, que en teoria permeten aconseguir temps de resposta més apropiats per a sistemes de T.R. Crides per bloquejar pàgines de memòria per impedir que el sistema de Memòria Virtual les posi al disc, evitant les seves enormes latències. Crides al planificador de processos perquè sempre executi primer els processos de temps real i en un ordre predible.

Especificacions POSIX Els estudis mostren una certa millora en les latències. Té sistemes de comunicació de processos més ràpids que els estàndard. Dóna tanta prioritat als processos de T.R. tant en temps de CPU com en pàgines de memòria física que la resta del sistema se’n ressenteix. Encara no és prou ràpid per moltes aplicacions. Molts dels problemes descrits anteriorment encara queden pendents de resoldre.

RTLinux Afegeix una capa de software entre el kernel i el controlador d’interrupcions. Quan salta una interrupció, no la captura el kernel, sinó que ho fa el subsistema RTLinux, ignorant les inhibicions d’aquestes. Intenta que totes les crides dels processos RTLinux siguin no bloquejants. Els processos RTLinux disposen de memòria compartida que els processos normals poden llegir i escriure.

RTLinux Disposa d’un planificador propi que alterna entre els processos de T.R. i el planificador normal de Linux. La major part del subsistema RTLinux són mòduls que es poden carregar dinàmicament al kernel.

RTLinux Flux de dades i control.

Una solució més general Actualment existeix un patch del kernel que el modifica permetent que els processos de sistema més prioritaris tinguin la oportunitat d’apropiar-se de la CPU quan estiguin a punt per executar-se, si es compleixen certes condicions respecte a les exclucions. També modifica el codi de retorn de les interrupcions, de manera que en retornar d’aquestes s’invoca el planificador de processos.

Una solució conceptualment més senzilla però... Un altre patch consisteix en una idea molt senzilla, si hi ha grans regions del codi del kernel que s’executen sense donar oportunitat als altres processos, perquè no “descansar” de tant en tant i deixar-los la CPU? És molt senzill d’explicar, però és difícil localitzar aquestes zones del codi, sobretot en un kernel de milions de línies! Si es canvia codi del kernel s’ha de tornar a fer tota la feina de localitzar aquestes regions i modificar el codi.

Quin resultat donen? Les tres últimes solucions aconsegueixen uns resultats molt bons, iguals o millors que els altres S.O. populars disponibles per a les plataformes Intel i compatibles. Les latències gairebé sempre són de l’ordre de microsegons.

El kernel actual Encara no s’han inclòs aquestes modificacions ni al kernel estàndard de Linux ni a l’experimental. En qualsevol moment alguna de les dues últimes podria ser afegida al kernel experimental. Per utilitzar-los es requereix un kernel força modern, modificar el codi font (procés automàtic) i recompilar.

Per què no s’han inclòs? Totes disminueixen el rendiment en moltes situacions, encara que el milloren en altres. Com que modifiquen el codi de les exclusions poden generar errors nous. Molta gent no considera que les capacitats de temps real siguin una prioritat.

Bibliografia http://www.kernel.org http://fsmlabs.com/community/