Algoritmi de planificare a proceselor

Programarea

Aspecte privind volumul de procesele care se desfășoară în sistem:

1. Fiecare proces rulează pentru aceeași perioadă de timp.

2. Toate lucrările ajung în același timp.

3. După ce a fost început, fiecare proces este finalizat.

4. Toate lucrările utilizează doar CPU-ul

5. Este cunoscută durata de execuție a fiecărui proces.

Programare

Dincolo de ipotezele privind procesele, avem nevoie de încă un lucru pentru a ne permite să
comparăm diferite politici de planificare: o valoare de planificare. O metrică este doar ceva pe care îl
folosim pentru a măsura ceva, și există o serie de valori diferite care au sens în programare.

Trebuie să rețineți că timpul de întoarcere este un metric de performanță

First In, First Out (FIFO)

Algoritmul de bază pe care îl putem pune în aplicare este cunoscut sub numele de First In, First

(FIFO) sau, uneori, primul venit, prima servit (FCFS).

FIFO are o serie de proprietăți pozitive: este clar, simplu si ușor de implementat. Și, având în vedere
ipotezele noastre, funcționează destul de bine.

De ce FIFO nu este cel mai bun?

O problemă care este este în general menționată este efectul de convoi, unde un număr de potențiali
consumatori de resurse relativ scurți intră în coada de așteptare, în spatele unui consumator de
resurse grele. Acest scenariu de programare ar putea să vă reamintesc coada de la un magazin
alimentar și cum vă simțiți atunci când vedeți persoana din fața dvs. cu trei căruțe pline de provizii și
un carnet de cecuri.

Cel mai scurt proces (SJF)

Se pare că o abordare foarte simplă rezolvă această problemă; de fapt este o idee furată din
cercetarea unor operațiunilor și aplicată planificarii proceselor în sistemele informatice. Această nouă
disciplină de planificare este cunoscuta sub numele de Shortest Job First (SJF), iar numele ar trebui să
fie ușor de amintit pentru că descrie politica destul de complet: rulează cel mai scurt job primul, apoi
cel mai scurt scurt, și așa mai departe.

Cel mai scurt timp până la finalizare (STCF)

Pentru a aborda această preocupare, trebuie să avem in vedere ipoteza 3 (că trebuie să fie terminat
fiecare proces). Pentru a face asta, avem nevoie și de niște mașini înăuntru programului în sine. SJF
prin definiția noastră este un planificator non-preemptiv și, prin urmare, suferă de probleme descrise
mai sus. Ori de câte ori un nou loc de muncă intră în sistem, programatorul STCF determină care
dintre celelalte lucrări (inclusiv noua lucrare) au mai rămas și le planifică. Ca și mai înainte, având în
vedere noile noastre ipoteze, STCF este probabil optim; având în vedere că SJF este optim dacă toate
procesele ajung la în același timp, ar trebui probabil să puteți vedea intuiția din spatele ei
optimalitatea STCF.

O nouă metrică: timpul de răspuns

Definim timpul de răspuns ca fiind timpul de la momentul în care lucrarea ajunge în sistem pentru
prima dată de când este programată.

STCF și disciplinele conexe nu sunt deosebit de bune pentru timpul de răspuns. Dacă sosesc trei
procese în același timp, de exemplu, al treilea proces trebuie să aștepte ca cele două locuri de muncă
anterioare să se desfășoare înainte de a fi programate o singură dată. În timp ce este excelent pentru
schimbare , această abordare este destul de rea pentru timpul de răspuns și interactivitate.

Round Robin

Pentru a rezolva această problemă, vom introduce un nou algoritm de programare, numit în mod
clasic ca programare rotundă-robinică. Baza acestei idei este simplă: în loc să executați lucrări până la
finalizare, RR lucrează pentru un proces (numită uneori un cuantum de programare) și apoi comută la
următoarea lucrare din coada de alergare. Ea face asta în mod repetat până la procesul terminat. Din
acest motiv, RR este uneori numit time-slicing. Rețineți că lungimea unei slice de timp trebuie să fie
un multiplu al perioadei de întrerupere a temporizatorului. Prin urmare, dacă temporizatorul
întrerupe la fiecare 10 milisecunde, ar putea fi o perioada de timp 10, 20 sau orice alt multiplu de 10
ms. Cu toate acestea, făcând fragmentul de timp prea scurt, apar probleme: brusc costul comutarii
contextului va domina performanța globală.

Costul de comutare a contextului nu apare numai din acțiunile OS de salvare și restaurare a câtorva
registre. Când programele rulează, ei construiesc o mulțime cache-uri CPU, TLB-uri, predictori de
ramură, și alte hardware pe cip. Trecerea la o altă lucrare provoacă această stare pentru a fi
spulberat și o nouă stare relevantă pentru locul de muncă care se desfășoară în prezent, ceea ce ar
putea exacta un cost de performanță notabil. RR, cu un fel de timp rezonabil, este deci un
programator excelent dacă timpul de răspuns este singura noastră valoare. Nu este surprinzător
faptul că RR este într-adevăr una dintre cele mai grave politici dacă timpul de întoarcere este măsura
noastră. Intuitiv, acest lucru ar trebui să aibă sens: RR face întinderea fiecărui proces atâta timp cât
poate, prin alergare fiecarui pentru un timp scurt înainte de a trece la următorul. Deoarece schimba
timpul doar când se termină procesele, RR este aproape pesimist, chiar mai rău decât simplu FIFO în
multe cazuri. În general, orice politică (cum ar fi RR) care este corectă, adică care împarte CPU între
procesele active pe o scară mică de timp, va efectua prost pe metrici, cum ar fi timpul de întoarcere.

Am dezvoltat două tipuri de programatori. Primul tip (SJF, STCF) optimizează timpul de reacție, dar
este rău pentru timpul de răspuns. Cel de-al doilea tip (RR) optimizează timpul de răspuns, dar este
rău pentru revenire. Și noi încă avem două ipoteze care trebuie să fie satisfacute: ipoteza 4 (că
procesele nu fac I / O), și ipoteza 5 (că timpul de execuție al fiecărui loc de muncă este cunoscut).

Încorporează I / O

Mai întâi vom relaxa ipoteza 4 - desigur, toate programele îndeplinesc I / O. Un planificator are în
mod normal o decizie atunci când un proces inițiază un I / O deoarece operația curentă nu va utiliza
CPU-ul în timpul procesului de intrare / ieșire; este blocat așteptarea finalizării I / O. Dacă I / O este
trimis la o unitate de disc, procesul ar putea fi blocat pentru câteva milisecunde sau mai mult, în
funcție de încărcarea I / O curentă a unității. Astfel, planificatorul ar trebui probabil să-și programeze
un alt proces pe CPU la momentul respectiv.Planificatorul trebuie, de asemenea, să ia o decizie când I
/ O completează. Când se produce acest lucru, se întrerupe, iar sistemul de operare funcționează și
se mișca.

Nu mai multe Oracle

Cu o abordare de bază I / O în loc, ajungem la presupunerea noastră finală: că planificatorul

cunoaște lungimea fiecărui proces. După cum am spus mai înainte, aceasta este probabil cea mai
proastă ipoteză pe care am putea-o face.

Multi nivele de feedback terminale

Problema fundamentală pe care MLFQ încearcă să o soluționeze este de două tipuri. În

primul rând ar dori să optimizeze timpul de întoarcere, care, se face prin rularea mai întâi a
locurilor de muncă mai scurte. În al doilea rând, MLFQ ar dori să facă un sistem ce se simte
receptiv la utilizatorii interactivi (adică, utilizatorii care stau cu ochii la ecran, așteptând
terminarea unui proces), reducând astfel la minimul de tine răspunsul ; din păcate, algoritmii
precum Round Robin reduc timpul de răspuns dar sunt teribile pentru timpul de întoarcere.

MLFQ: Reguli de baza

Pentru a construi un astfel de planificator vom descrie elementele algoritmilor de bază. D

esi specificul multor dintre MLFQ-urile diferă, cele mai multe abordări sunt similare. Aici,
MLFQ are un număr de cozi distincte, fiecare aloca un alt nivel de prioritate. În orice
moment, un loc de muncă este gata pentru a rula pe o singură coadă. MLFQ folosește
prioritățile pentru a decide ce proces ar trebui să ruleze la un moment dat: un proces cu o
prioritate mai mare (adică un loc de muncă pe coada superioară) trebuie ales să funcționeze.

Astfel, ajungem la primele două reguli de bază pentru MLFQ:

• Regula 1: Dacă Prioritatea (A)> Prioritatea (B), A rulează (B nu).

• Regula 2: Dacă Prioritatea (A) = Prioritatea (B), A & B rulează în RR.

Prin urmare, cheia pentru programarea MLFQ constă în modul în care planificatorul
stabilește priorități. În loc să ofere o prioritate fixă pentru fiecare proces, MLFQ variază
prioritatea unui loc de muncă pe baza comportamentului observat. Dacă, de exemplu, un
proces, în mod repetat renunță la procesor în timp ce așteaptă intrarea de la tastatură,
MLFQ își va menține prioritatea ridicată, deoarece astfel este un mod interactiv despre cum
procesul s-ar putea comporta. Dacă, în schimb, un loc de muncă utilizează CPU intens pentru
mult timp, MLFQ își va reduce prioritatea. În acest fel, MLFQ va încerca să învețe despre
procesele pe care le desfășoară și, astfel, să folosească istoria meseriei, să prezică viitorul
său comportament.

Încercarea 1: Modificarea priorității

Acum trebuie să hotărâm cum MLFQ va schimba nivelul de prioritate a unui proces (și, prin
urmare, a cărei coadă este p) pe durata de viață a unui loc de muncă. A face acest lucru,
trebuie să ținem cont de volumul de muncă: un mix de locuri de muncă interactive care sunt
scurte (și pot renunța frecvent la CPU) și unele care rulează mai mult timp "CPU-bound",
care necesită mult timp CPU, dar unde timpul de răspuns nu este important.

Iată prima noastră încercare pentru un algoritm de ajustare a priorităților:

• Regula 3: Când un loc de muncă intră în sistem, acesta este plasat la cel mai înalt
nivel(coada de sus).

• Regula 4a: Dacă o lucrare folosește o întreagă bucată de timp în timp ce rulează,
prioritatea sa este redusă (adică se mișcă în jos într-o coadă).

• Regula 4b: Dacă o lucrare renunță la CPU înainte ca fragmentul de timp să crească, rămâne

la același nivel de prioritate.

Încercarea 2: Îmbunătățirea priorităților

Să încercăm să schimbăm regulile și să vedem dacă putem evita problema. Ideea simplă aici.
Trebuie sa sporim periodic prioritatea tuturor proceselor în sistem. Există multe modalități
de a realiza acest lucru, cum ar fi: aruncarea tuturor în coada de sus; prin urmare, reiese o
nouă regulă:
• Regula 5: După o perioadă de timp , mutați toate lucrările din sistem la coada de sus.

Încercarea 3: o mai bună contabilitate

Acum avem încă o problemă de rezolvat: cum să împiedicăm jocurile planificatorul nostru?
Adevăratii vinovati aici, sunt Regulile 4a și 4b, care lăsau un proces să-și păstreze prioritatea
renunțân la CPU înainte de expirarea intervalului de timp.

Soluția de aici este de a realiza o mai bună contabilizare a timpului CPU la fiecare nivel al
MLFQ. Planificatorul ar trebui să țină pasul; odată cu un proces a folosit alocarea sa, este
retrogradat la următoarea coadă prioritară. Dacă folosește fragmentul de timp într-o
explozie lungă sau multe explozii mici, nu contează.

Prin urmare, rescriem regulile 4a și 4b la următoarea regulă unică:

• Regula 4: Odată ce un loc de muncă își utilizează alocarea de timp la un anumit nivel
(indiferent de câte ori a renunțat la CPU), prioritatea acestuia este redusa (adică se mișcă în
jos într-o coadă).

Tuning MLFQ și alte probleme

O mare întrebare este cum să parametrizezi un astfel de program. De exemplu, câte cozi ar
trebui să fie? Cât de mare ar trebui să fie fragmentul de timp pe coadă? Cât de deasa ar
trebui să fie prioritatea pentru a evita strangularea și pentru a ține cont de schimbările de
comportament? Nu există răspunsuri ușoare la aceste întrebări și astfel, doar o anumită
experiență cu volumul de lucru și reglarea ulterioară a planificatorului va duce la un echilibru
satisfăcător.

MLFQ: Rezumat

Am descris o abordare de planificare cunoscută sub denumirea de Multi-Level Feedback

Queue (MLFQ). Acum putem vedea de ce se numeste asa: are mai multe niveluri de cozi și
utilizează feedback pentru a determina prioritate unui anumit loc de muncă. Istoria este
ghidul său: să acorde o atenție la procese, să se comporte în timp și să le trateze în
consecință.

Setul de reguli MLFQ, răspândit în tot capitolul, este reprodus aici:

• Regula 1: Dacă Prioritatea (A)> Prioritatea (B), A rulează (B nu).

• Regula 2: Dacă prioritatea (A) = Prioritatea (B), A & B rulează în mod robinic cu ajutorul
fantei de timp (lungimea cuantică) a coadministrării date.

• Regula 3: Când un loc de muncă intră în sistem, acesta este plasat la cel mai înalt nivel

prioritate (coada de sus).

• Regula 4: Odată ce un loc de muncă își utilizează alocarea de timp la un anumit nivel
(indiferent de câte ori a renunțat la CPU), prioritatea acestuia este redusa (adică se mișcă în
jos într-o coadă).

• Regula 5: După o perioadă de timp , mutați toate lucrările din sistem la coada de sus.
 Bibliografie

1. http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf
2. http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched.pdf