Lucrând pe un computer, trebuie să ne confruntăm în mod constant cu diferite tipuri de întârzieri. Încercați să compilați kernelul în același timp, să ascultați muzică, să descărcați filme pe grilă și să introduceți text în OpenOffice.org. Sunt sigur că, mai devreme sau mai târziu, veți vedea că semnele din Writer vor apărea în câteva secunde după ce faceți clic pe butoanele tastaturii și jucătorul va bâlbâi în mod constant. Cum puteți reduce timpul de răspuns al aplicațiilor în Linux - sistemul de operare de partajare a timpului. unde toate procesele sunt egale (bine, aproape)? La urma urmei, a fost dezvoltat cu accent pe optimizarea performanțelor sistemului în general și nu a fost vorba de asigurarea unui timp limitat de răspuns la aplicații.
Folosim mijloace improvizate
După cum știți, viața sistemului este dată de procese care joacă un rol-cheie în orice sistem de operare. de bază de cauciuc nu este, și în ciuda frecvenței gigahertzi exorbitanta pe unitatea de timp se poate executa instrucțiuni de doar un singur proces (cuanta de timp se numește utilizarea procesorului), și poate fi foarte multe procese în sistem ei înșiși. Deci, pentru a reduce întârzierile, numărul de procese trebuie minimizat. Pentru a face acest lucru, nu trebuie doar să eliminați toate programele inutile și să dezactivați toți demonii neutilizați, dar și să reconstruiți nucleul, lăsând doar funcționalitatea cu adevărat necesară.
Pentru a aloca resursele culturale și a nu priva cineva de acest lucru, în orice sistem există un subsistem de management al procesului. lucrând pe principiul "fiecăruia în funcție de abilitățile sale, fiecăruia în funcție de lucrarea sa". Procesul poate funcționa în două moduri: în modul kernel (modul kernel) și în modul utilizator (modul utilizator). unde execută instrucțiuni simple care nu necesită date "sistem" speciale. Dar când sunt necesare astfel de servicii, procesul va intra în modul kernel, deși instrucțiunile vor fi executate în continuare în numele procesului. Toate acestea se fac în mod special pentru a proteja spațiul de lucru al kernel-ului din procesul utilizatorului. Procesele rămase sunt fie gata de lansare, așteaptă ca planificatorul să le aleagă, fie sunt în modul somn (adormit), așteptând resursele care nu sunt disponibile în prezent. Cu acesta din urmă totul este simplu. Când un semnal provine de la un dispozitiv controlat, procesul se declară TASK_RUNNING și devine în coada de gata. Dacă are cea mai mare prioritate, kernelul trece la execuția sa.
Dar există o altă expresie. Când procesul furnizează resurse de sistem, există un așa-zis comutator de context. care păstrează imaginea procesului actual (care, de altfel, ia ceva timp, astfel încât latența, chiar și în cazul ideal, nu va fi zero). Deci, schimbarea contextului, atunci când procesul este în modul kernel, poate să prăbușească întregul sistem. Prin urmare, un proces cu prioritate ridicată va trebui să aștepte cu răbdare în momentul trecerii la modul de lucru, iar acest lucru se poate întâmpla în două cazuri: lucrarea este terminată sau resursele necesare nu sunt disponibile. Adică, pentru a asigura un timp de răspuns mai scurt, este necesar să minimizăm numărul de sarcini nucleare. Dar pentru o astfel de decizie este necesar să plătim stabilitatea generală și "greutatea" codului. Microkernel este, de altfel, a vândut mult mai bine - există un set minim de bază de modulare altceva atârna ca un pom de Crăciun, care oferă versatilitate și vă permite să proiecteze sistemul pentru sarcini specifice.
În ceea ce privește planificarea procesului, este legată de prioritate. Planificatorul selectează pur și simplu următorul proces care are cea mai mare prioritate. În acest caz, procesul mai puțin prioritar care se desfășoară în acel moment nu poate chiar să-și elaboreze cuantumul până la capăt. Fiecare proces are două tipuri de priorități: relativă (p-> nice, implicit până la 100 de niveluri de prioritate), setată la pornirea aplicației și cea curentă, pe baza căreia are loc planificarea. Valoarea priorității curente nu este fixă, dar este calculată dinamic și depinde în mod direct de frumos. Valoarea stabilită de utilizator poate fi în intervalul de la -20 până la +19, iar aplicația cu o prioritate mai mare corespunzătoare -20 și +10 (implicit) și mai mare sunt considerate deja sarcini cu prioritate scăzută. De exemplu, pentru a rula un program cu o prioritate mai mare decât de obicei, facem acest lucru:
$ sudo frumos - 20 mplayer
Și cu un inferior:
$ sudo frumos -20 de locuri de muncă # 038;
Pentru a modifica prioritatea relativă a unui proces, utilizați ID-ul procesului, și nu numele:
$ sudo renice - 20 PID
Prioritatea actuală depinde de resursele de sistem drăguțe și consumatoare de timp. Se recalculează cu fiecare bifă și în timpul ieșirii din modul kernel. În sisteme diferite, acest lucru se întâmplă în formulele lor, în cel mai simplu caz, o prioritate este împărțită în două, iar când acesta ajunge la zero complet recalculat (restaurat). Acest mecanism vă permite să obțineți timp și cereri de prioritate scăzută, dar în cele din urmă marea prioritate a primi cea mai mare parte.
Toate aceste subtilități au fost folosite în diferite patch-uri de implementare lowlatency pentru kernel 2.4. Nu s-au înlocuit doar algoritmii actuali de recalculare prioritară, ci toate constantele posibile (de exemplu, limita plăcută a fost mărită la 256), în plus, un timer a fost setat cu o frecvență de până la 1000 Hz.
Pentru a indica aplicația care necesită o atenție specială din partea procesorului poate fi utilizat și încorporate în caietul de sarcini POSIX în timp real apela SCHED_FIFO (un fel de tranziție de la un mod în timp real „moale“). Un rezultat similar este realizat prin utilizarea de apeluri SCHED_RR, CAP_IPC_LOCK, CAP_SYS_NICE sau prin substituirea valorilor sys_sched_get_priority_max - o funcție care returnează prioritatea maximă în timp real. Este utilizarea SCHED_FIFO cauzele care XMMS jucător pentru a rula sub rădăcină, aproape balbism chiar și la sarcini exorbitante pe sistem.
Problema principală în timp real este capacitatea de captare a resurselor dintr-un proces cu prioritate redusă. mai ales dacă rulează în modul kernel. La urma urmei, chiar și schimbarea de context este petrecută ceva timp. Sute de dezvoltatori din întreaga lume au încercat să folosească miliardele de tehnologii: posibilitatea de întrerupere în timpul execuției în modul nucleu (kernel preemptible, kernel-ul este descărcat) la o moștenire temporară (moștenesc) o prioritate în timp real a unei cereri de prioritate redusă. astfel încât să poată termina repede secțiunea critică a codului și să dea controlul.
Subiectul miezului descărcat a fost de interes pentru public chiar și în perioada de dominare a sucursalei 2.2. Linus Torvalds a spus că în timp real este o idee proastă și, pentru moment, preemptibilă, a fost implementată exclusiv prin intermediul patch-urilor. Dar deja la pregătirea ramurii 2.6 la codul sursă a fost adăugată capacitatea de a descărca kernelul (PREEMPT_RT). Preemptible-kernel este implementat, de regulă, sub forma unui al doilea kernel. Dacă procesul îl accesează cu o cerere, sistemul principal este blocat de fapt pe durata executării acestuia. Totul este implementat ca un modul descărcabil care înlocuiește / interceptează cele mai importante funcții care pot duce la întârzieri. Dar nu totul este atât de simplu. Într-un interviu cu unul dintre inginerii MontaVista (compania-dezvoltator de una dintre soluțiile în timp real bazate pe Linux), a spus că, în kernel 2.6 aproximativ 11.000 de bucăți de cod este pur și simplu imposibil de a face preemptible.
Pe Internet, dacă priviți cu atenție, puteți găsi un număr suficient de patch-uri diferite care permit implementarea în timp real în Linux, dar, de regulă, majoritatea proiectelor sunt deja învechite și oferă modificări ale kernel-ului 2.4. De exemplu, KURT-Linux (www.ittc.ku.edu/kurt) și RT-Linux (www.rtlinux.org). Ambele Linux utilizează tehnologii similare, iar diferențele subiective în munca lor nu sunt vizibile, dar toată lumea laudă RT-Linux pe Internet. Puteți găsi computerele aflate sub controlul acestuia pe generatoarele Tokamak, spitalele din Peru, sateliții NASA și simulatoarele F111-C. Apropo, dacă accesați search sudo apt-cache în timp real în Ubuntu, veți găsi un pachet cu vechea versiune 3.1pre3-3 a RT-Linux.
Patch kernel
În kernelul standard, executați utilitarul rt-test. numai prin rulare, ajungem la o valoare de 0.125 ms, iar încărcarea crește până la 15.402 ms. Ar trebui să acordați atenție parametrului Criteria, care este de 100 microsecunde. În cazul nostru, rezultatul testului este FAIL, adică înaintea datei în timp real. Am pus un kernel lowlatency - kernel-ul obișnuit, dar cu un timer de 1000 Hz și un timp de răspuns redus:
$ sudo apt-get instalează linux-lowlatency
Reporniți și rulați rt-test din nou.
$ sudo rt-test toate
Valoarea de latență de pornire este acum 0,073 ms, iar latența maximă este de 2,907 ms. Deja mai bine. Deși Criteriile sunt încă nereușite, dar muzica din Amarok'e cu o încărcare decentă a sistemului nu mai este întreruptă.
Dintre toate soluțiile pentru implementarea în timp real a sistemului, numai unul oferit de Ingo Molnar a supraviețuit până în prezent. Se zvonea că patch-uri (www.kernel.org/pub/linux/kernel/projects/rt) emise de acesta va fi inclus în kernel 2.6.22, dar până ce se întâmplă. Pentru a instala rt fanilor Fedora, trebuie doar să introduceți yum install kernel-rt, restul va trebui să compileze puțin. Descărcați și aplicați patch-ul în kernelul dvs.:
$ wget -c www.kernel.org/pub/linux/kernel/projects/rt/older/patch-2.6.22.1-rt9
$ tar xjvf linux-2.6.22.1.tar.bz2
$ cd linux-2.6.22.1
$ sudo patch -p1
Un număr de parametri suplimentari vor fi găsiți în timpul configurării. Printre ei Tickless System (Dynamic Căpușele) (NO_HZ) - modifica dinamic capusa; Suport de înaltă rezoluție temporizator (HIGH_RES_TIMERS) - de înaltă rezoluție cronometru. În secțiunea preemțiune Modul ne interesează complet preemțiune (Real-Time) (PREEMPT_RT), cu toate că încă disponibil nr forțată preemțiune (Server) (PREEMPT_NONE), voluntar Kernel preemțiune (desktop) (PREEMPT_VOLUNTARY), Preemptible Kernel (Low-Latency Desktop) (PREEMPT_DESKTOP ). În secțiunea «strat de bloc - Standard I / O planificator» a apărut complet echitabil CFS coadă planificator.
După repornirea sistemului, prin introducerea dmesg, puteți vedea că kernel-ul a fost PREEMPT RT, ceasul timer-ul este instabil ( «Clocksource TSC instabil»), și PS AUX arată prezența unui număr mare de noi procese. Dar suntem mai interesati de rezultatul testului rt. Deci, toate trucurile noastre au condus la ceea ce este acum latenta maximă este mai mică de 0,07 ms. Voila, testul a trecut!
Trimiteți-le prietenilor: