1 / 47

OPERÁCIÓS RENDSZEREK

OPERÁCIÓS RENDSZEREK. Ütemezés és a Context Switch. A mai program. A CPU ütemezéshez fogalmak, alapok, stratégiák Időkiosztási algoritmusok VAX/VMS, NT, Unix időkiosztás A Context Switch implementáció. Fogalmak. Erőforrásokat Hozzárendelünk processzekhez (allokáció);

ovid
Download Presentation

OPERÁCIÓS RENDSZEREK

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OPERÁCIÓS RENDSZEREK Ütemezés és a Context Switch

  2. A mai program • A CPU ütemezéshez fogalmak, alapok, stratégiák • Időkiosztási algoritmusok • VAX/VMS, NT, Unix időkiosztás • A Context Switch implementáció Vadász

  3. Fogalmak • Erőforrásokat • Hozzárendelünk processzekhez (allokáció); • A használatukat időben beosztjuk (időkiosztás, scheduling); • Kapcsoljuk azokat a kiosztott időpillanatban (dipatching és switch). • Most a processzor „üzemezésről” lesz szó • (Az egyéb erőforrás ütemezés kérdéskör a „kölcsönös kizárás’ probléma kezelésénél előjön majd …) • A CPU meglehetősen fontos (és jellegzetes) erőforrás. Érdemes ütemezését külön tárgyalni. Vadász

  4. A probléma • Több processz van, mint processzor … • A processzek osztozzanak egy CPU idején. (Tegyük fel: minden processzhez rendeltek (ez az allokáció) egy CPU-t.) • Emlékezz a processz állapotokra: • ha letelt az időszelete a futó processznek, • Vagy ha maga blokkolt állapotba megy (ezzel „lemond” a CPU-ról), • akkor a futásra kész processzekből válasszunk ki egyet (ez a scheduling), és • „kapcsoljuk neki” a CPU-t (ez a dispathing és a Context Switch második fele). Vadász

  5. Tágítjuk a problémát: ütemezési szintek • Long-term-scheduling (hosszútávú) • JOB ütemezés: JOB/taszk pool-ból melyiket válasszuk ki futásra. A multiprogramozási szintet befolyásolja. • Medium-term-scheduling (középtávú) • suspended (futásra nem kész, partially executed, outswapped) processzek közül melyeket helyezzük futásra késszé (memória igény is érdekes) • Short-term-scheduling (rövidtávú) • futásra kész processzek közül melyik kapja a CPU-t. • A továbbiakban ezzel foglalkozunk. (Ezzel ismét szűkítünk.) Vadász

  6. Mit várunk el? • Pártatlanság: minden processz (taszk) korrekt módon, de nem feltétlenül egyenrangúan kapja meg a processzort • Hatékonyság: a CPU lehetőleg legnagyobb százalékban legyen kihasználva • Válaszidő (interaktív felhasználóknak): elfogadható legyen • Fordulási idő (kötegelt munkák): elfogadható legyen • Teljesítmény: időegységre eső JOB, taszk, processz feldolgozás (más, mint a CPU kihasználás!) jó legyen Látható ellentmondások! Vadász

  7. Technikai alapok • Óraeszköz periodikusan megszakításokat generál • Az időt szeletekre (time slice, quantum) bonthatjuk • A CPU felhasználás idejét, a processzek életidejét stb. számon tarthatjuk • Bizonyos időnként az állapotokat kiértékelhetjük, és CPU kapcsolást valósíthatunk meg Vadász

  8. Az óraeszköz • A programozható óra 3 komponensből áll: • oszcillátor kristály: nagy pontossággal periodikusan jeleket generál (tipikusan 5 - 100MHz). • Számláló (counter): ami dekrementálja az értékét minden a kristály által generált jelre. Mikor a számláló eléri a 0 értéket, IT generálódik. • Tartó regiszter (holding register): az óra indulásakor (one-shot mode) vagy a counter 0-vá válásakor (square-wave-mode) tartalma betöltődik a számlálóba, ezzel szabályozhatjuk, milyen gyakran keletkezzen IT (clock tick rate). • Pl. egy 1MHz-es kristály (1s-ként ad jelet), 16 bites regiszterekkel programozható 1s-től 65535 s-ig tartó óra ütés (clock-tick) tartományba. Vadász

  9. Az óraeszköz IT kezelőjének feladatai • A napi idő karbantartása, • a futó processz által felhasznált CPU idő számolására, • a processz időkvantuma lejártának megállapítására, ütemező meghívására, • alarm szignál generálására (amikorra azt egy processz igényelte), • "watchdog timer"-t biztosíthat (pl. floppy kezelésnél: felpörgetés, lehet I/O; ugyanekkor indul a wd-timer, ami leállítja a pörgetést, ha nem jön újabb i/o kérés) • Segíti a profiling-ot, monitoring-ot, statisztikáz. Vadász

  10. Napi idő karbantartás • Egy számláló (64 bites) a napi időt (time-of-day) nyilvántartja óra-ütésekben (clock-tick), vagy 2 számláló: sec-ben + "ütésszám a kurrens sec-ben" (32 bit a sec-nak, 16 bit tickeknek) • egy fix időhöz képest (Unix: 1970. jan 1. 12:00-tól) • a bootolási időtől (32 bit a tick-számlálónak, 32 bit a sec-ben mért betöltési időnek). • A rendszergazda által adott dátum-idő átszámítódik clock-tick-ekbe, és beíródik a számlálóba. • Az óra kezelő (clock driver, clock IT handler) ütésenként növeli ezt a számlálót (számlálókat) Vadász

  11. CPU idő nyilvántartás • A processzhez tartozó számláló ütésenként inkrementálódik, ha a processz futó állapotú. • Megoldható, hogy külön számláljuk a felhasználói módú és a kernel módú CPU használatot (persze, kis hibák itt lehetnek). Az idő-szelet nyilvántartása • A quantum, time-slice nyilvántartáshoz a context switch esetén egy számlálót (akár processzenkénti számlálót) feltöltünk óra-ütésekben mért időszelet értékkel, majd ezt ütésenként dekrementáljuk. • A számláló 0-vá válása jelzi a quantum lejártát Vadász

  12. Időzítő (alarm, watchdog-timer) Következő szignál Kurrens idő 4200 3 Clock header 3|S1 4|S2 6|S3 • Idők lejártát ütésekben (tickek-ben) adott számlálók 0-vá válása jelezheti. • Számlálók (órák) időben rendezett láncolt listáját tartjuk fel, a számlálókban a következő szignál ideje (tick-ben). • A lista elején lévő számlálót dekrementáljuk. • Pl. Kurrens idő: 4200, S1:4203, S2:4207, S3:4213 Vadász

  13. Vissza az ütemezéshez: technikai alapok • Óraeszköz periodikusan megszakításokat generál • Az időt szeletekre (time slice, quantum) bonthatjuk • A CPU felhasználás idejét, a processzek életidejét stb. számon tarthatjuk • Bizonyos időnként az állapotokat kiértékelhetjük, és CPU kapcsolást valósíthatunk meg Vadász

  14. Döntési stratégiák • Nem beavatkozó (non-preemptive) • run-to-completion jellegű • együttműködő (kooperative) • Szelektív beavatkozó • Beavatkozó (preemptive): akkor is elveszik a CPU-t egy processztől, ha az nem akar lemondani róla Vadász

  15. Ütemezési döntési helyzetek • Egy processz wait állapotátmenete. • Egy processz preemption állapotátmenete (pl. megszakítás bekövetkezése miatt). • Egy processz signal állapotátmenete. • Egy processz terminálódása. (4) exit running schedule/run (1) sleep/wait/request (2) preempt (3) signal/assign blocked ready waiting Vadász

  16. Ütemezési döntési helyzetek • Egy processz wait állapotátmenete. • Egy processz preemption állapotátmenete (pl. megszakítás bekövetkezése miatt). • Egy processz signal állapotátmenete. • Egy processz terminálódása. A processz szempontjából az 1. és 4. helyzet nem döntési helyzet. Az viszont a 2. és a 3. számú. Ha ütemezési döntések csak az 1., 4. helyzetekben lehetségesek: nem beavatkozó az ütemezés. Vadász

  17. A leegyszerűsített forgatókönyv • A futó processz ideje lejárt (egy logikai óra, számláló lejárt, ütésére egy IT kezelő működésbe lép), vagy a futó processz blokkolt állapotba menne; • A kezelő (a sheduler) kiértékel, és kiválasztja a futásra kész processzekből a „nyertest” (ez egy prioritás számítás, optimum számítás); • Majd megtörténik a „kapcsolás” … Vadász

  18. Mi befolyásolhatja a kiválasztást? • Prioritás = fontosság. Mi befolyásolhatja? • A processzek memóriaigénye • A processzek „érkezési ideje” vagy „érkezési sorrendje” • Az eddigi CPU felhasználási idő* • Vö.: CPU lázas processzek szemben I/O lázas processzek • A várható CPU felhasználási idő* • Vö.: Számolásigényes processzek szemben I/O igényes processzek. • Vajon lehet-e időt becsülni? • A processz „időszerűsége”** • Vö.: interaktív processzek szemben kötegelt munkák, • CPU lázas szakaszok szemben az I/O lázas szakaszok. • Rendszer terhelés befolyása. • Valós idejű processzek problémája kezelendő. Vadász

  19. Egy kis fogalom magyarázat … • A processz életében lehetnek • CPU lázas időszakaszok (CPU burst) • I/O lázas időszakaszok (I/O burst) • Vannak • Számolásigényes (CPU bound) processzek (hosszú CPU lázas szakaszokkal); • I/O igényes (I/O bound) processzek (rövid CPU lázas szakaszok, sok I/O lázas szakasz). Vadász

  20. Melyik ütemezési prioritása legyen magasabb? Fut Fut Ready Blokkolt Ready Blokkolt Egy processz állapotátmenetei CPU lázas időszakában Egy processz állapotátmenetei I/O lázas időszakában Vadász

  21. Az ütemezési algoritmusok • Mi (milyen) a prioritásfüggvény? • Az igény-bejelentési sorrend (First Come, First Served) (Long- és Medium-term ütemezéshez) • A legkisebb igény (Shortest Job First) (Long- és Medium-term ütemezéshez) • Valamilyen ígéret (ígéret-vezérelt időkiosztás) (Policy Driven Scheduling) • Körkörös sorrend (Round-Robin Scheduling) • Több összetevőtől függő (Többszintes prioritás-sorokon alapuló visszacsatolásos) (Multilevel Feedback Queue Scheduling) Vadász

  22. First Come, First Served • A processzek készletében (Process Pool) lévő processzek a beérkezési sorrendjük szerint kapnak CPU-t. • Egyszerű a megvalósítás. • Kialakulhat a „convoy effect”: korábban érkezett CPU lázas szakaszú processz lefogja a CPU-t. (Országúton lassú jármű mögött sorban a gyorsabbak) Vadász

  23. Shortest Job First • Régi, egyszerű. • A nyomtató kiszolgálási sorokból ütemezésre még ma is használják. • Az átlagos fordulási idő a legkisebb. • CPU ütemezéshez: hogyan lehetne megmondani előre a várható időigényt? • Idősorozatokkal jellemezhető munkákhoz az aging (öregedés) algoritmus. Vadász

  24. “Aging “ algoritmus 0, 1, 2, ...,i,.. CPU lázas szakaszok ismétlődnek (nem egyforma időt igényelve). Becsülhetjük a következő idejét (Ti : tényleges, mért; Bi: becsült): Bi+1 = a * Ti + (1 - a) * Bi ; ahol 0 <= a <= 1. Legyen a = 1/2, ekkor (a: súlyozó faktor) Bi+1 = (Ti + Bi ) / 2 Vadász

  25. Policy Driven Scheduling • Reális ígéret: n számú processz esetén 1/n-ed részét kapja egy processz a CPU-nak. • Mérni kell az • élet-idő-t (a rendszerben eddig eltöltött idejét), és • cpu-idő-t (eddig felhasznált CPU időt), számítandó a • jogosultsági-idő = élet-idő / n; • prioritás = jogosultsági-idő / cpu-idő. • Más ígéretek is lehetnek • Az ígéret-vezérelt időkiosztás speciális esete a valós idejű (Real Time) időkiosztás. Vadász

  26. Round Robin Egyszerű, elég régi algoritmus. Időszeleteket (quantum) rendelünk a processzekhez. • A kész állapotú processzek egy soron nyilvántartottak. • Egy processz futhat, amíg a időszelete tart (ha blokkolódik, akkor addig sem fut). • Lejárt szeletű (preempted) processz a sor végére kerül. • A sor elején álló kapja a CPU-t. A listán a processzek “körben“ járnak. Vadász

  27. Multilevel Feedback Queue Scheduling • Több ready sor van, a különböző prioritási szintekhez • Elvileg lehet minden sorhoz más-más scheduling/prioritás algoritmus • Pl. interaktív processzekhez preemptív FCFS, vagy MLFQ • Batch processzekhez SJF • Valós idejű (Real Time) processzekhez fix prioritás • Minden sorhoz rendelhetünk időszeletet • Kell egy módszer: mikor, mennyivel csökkentsük a prioritást • Kell egy módszer (algoritmus), mikor mennyivel növeljük a prioritást (visszacsatolás) • Preempted/blocked/signaled processz a neki megfelelő sor végére kerüljön • Kell egy módszer, melyik sorról "kapcsoljunk" • Pl. a legegyszerűbb: a legmagasabb sorról az elsőt. Vadász

  28. VAX VMS scheduling • Multilevel feedback jellegű, alkalmas real time-ra is. • 32 prioritási szint. Nagyobb szám: nagyobb prioritás. • 16-32: a valós idejű processzek számára. Nem dinamikus! • 0-15: reguláris processzeknek, dinamikusan számítódik. • A processz bázis-prioritása: minimális prioritása. • Rendszerhívásokhoz rögzített prioritás növekmény. Mikor a processz futásra késszé válik, a növekmény hozzáadódik a bázis-prioritáshoz, és a megfelelő sorra kerül processz. • Scheduled processz prioritása egy szinttel csökken (határ a bázis-prioritás). Ha elveszik tőle a CPU-t, erre az új sorra kerül. • Sokáig várakozókat eggyel följebb emelik (no starvation). • A scheduler a legmagasabb prioritás sor elejéről választ. Vadász

  29. Unix időkiosztás 0 Kernel mód prioritás-tartomány Küszöb prioritás User mód prioritás-tartomány n Vadász

  30. A Unix időkiosztása • A processzeknek user-mode vagy kernel-mode prioritásértéke lehet. Az előző dinamikus, ezek lehetnek preempted processzek. Utóbbi fix érték. Ezekre nincs preempció. • Küszöb prioritás szint elválaszt. • A user-mode prioritások (p_usrpri) dinamikusan “igazítódnak“. • A p_cpu mező a futó processznél a CPU használattal arányosan nő. • A p_cpu mezőt quantumonkként öregbítik (aging): p_cpu = p_cpu / const1; (rendszerint const1 = 2). Vadász

  31. A Unix időkiosztása2 • A prioritás kiszámítódik (kisebb érték jelenti a nagyobb prioritást!): p_usrpri=PUSER+p_cpu/const2 + p_nice/const3; (Rendszerint const2=const3=2;). • A PUSER a processz bázisprioritása, külső prioritás. • A p_nice a nice() rendszerhívással (felhasználói kontrollt lehetővé tevő) beállított érték. • A p_usrpri a küszöb érték alá, egy beállított érték fölé nem mehet. Vadász

  32. Egy példa Egy rendszerben a PUSER=60. Ha egy processz megkapja a CPU-t és quantumában végig használja, a p_cpu növekmény legyen 60. Legyen 3 processz (A, B, C), induláskor a C p_cpu-ja 7, a másik kettőé 0. Induláskor a p_uspri C-nél 63, a másik kettőnél 60. Mindhárom processznél a p_nice érték 0 legyen. Követhetjük, hogyan változnak a prioritások, melyik processz kap CPU-t. Vadász

  33. BSD 4.3 Scheduling • Quantum=0.1 sec; const2=4; const3=2; • const1 dinamikusan számítódik: • const1=(2*load+1)/(2*load); ahol • load a run queue álagos hossza az utóbbi 1 percben • Ugyanekkor a p_cpu öregbítés nem quantumonként, hanem 1 sec-enként történik csak! • Az 1 sec-nél hosszabb ideig blokkolt processzeknél • const1 a blokkolási időtől is függ! Vadász

  34. NT Scheduling a fonalakra • Van standby állapot is: a legnagyobb prioritású futásra kész. A standby-t ütemezik ki. • 32 prioritási szint, 16-31: valósidejű, 0-15: normál, változó (mint a VAX/VMS-nél) • Lejárt quantumú fonál prioritás 1-gyel csökken (a bázisig). • Kész állapotba jutó fonál prioritása növekszik, a blokkolódása típusától függően • A legmagasabb kész sor első fonala standby állapotúra változik. Ha nincs ilyen, az idle fonál lesz standby. Vadász

  35. Linux scheduling • A POSIX 1003.4-nek megfelelően több ütemezési osztály van (processzenként beállítható) • SCHED_FIFO, SCHED_RR, SCHED_OTHER • A schedule() függvény hívódik • ha processz blokkolt állapotba megy, • Minden syscall és "slow" IT után, ha egy flag beállított. • A schedule() függvény 3 dolgot csinál • "szokásos" teendőket (miknek az óra IT kezelőben kellene lenniük, de "hatékonyság" miatt itt vannak) • Legmagasabb prioritású processz meghatározása • Context Switch Vadász

  36. A CPU allokálás: Context Switch • A futó processz hardver kontextusát (dinamikus részét) lementjük valahová, • a kiválasztott processz kontextusát felvesszük. • Legfontosabb a programszámláló (PC, IP) lementése, felvétele. • Lementés történhet • wait (blokkolódás) állapot-átmenetnél, vagy • preemption állapot-átmenetnél is. • A felvétel schedule átmenetet okoz. Vadász

  37. Hova mentsük le a dinamikus kontextust? Lehetne • a Process Table sorába (PCB-be). Hátrány: nagy lesz a tábla, a lementés/felvétel hardveresen nem támogatott. • Veremtárba. Előny: hardveres push/pop is van. • Felhasználói szintű verembe? Nem. • Közös kernel verembe? • Processzenkénti kernel verembe? • Egyes CPU-kban többszörös regiszterkészlet! • Egyes CPU-knak van védett módú processz kapcsolás gépi instrukciójuk! Vadász

  38. Unix processz kontextus komponensek A kontextus statikus része A kontextus dinamikus (volatile)része Felhasználói szintű kontextus • Program szöveg • Adatok • Veremtár • Osztott adatok Keret a 3. rétegnek Rendszer szintű kontextus statikus része Keret a 2. rétegnek • Process Table bejegyzése • U Area • Processzenkénti Region Table Keret az 1. rétegnek Felhasználói szint Vadász

  39. Egy lehetséges mechanizmus • Lásd a Unix processz kontextus ábrát (előző dia): keretek a processz kernel veremben a dinamikus kontextus részére. • Hány keret kell? Mikor keletkezik új réteg? • rendszerhívással (trap) belépünk a kernelbe; • megszakítással belépünk a kernelbe; • preemption következett be. • Megszűnik egy réteg, ha • rendszerhívásból visszatérünk user szintre; • megszakítás kiszolgálásból vissztérünk; • schedule átment következett be. Vadász

  40. A kapcsolás lépései • Döntés, legyen Context Switch. • A save-context() algoritmussal a kurrens processz dinamikus kontextusának lementése; • A “legjobb“ processz kiválasztása (scheduling algoritmusok!) • A resume-context() algoritmussal a kiválasztott processz kontextusának felvétele. Tételezzük fel: R0 regiszterben van a függvények visszatérési értéke, PC a programszámláló, PSW a státus regiszter. Ezekre van hardveres push/pop. Vadász

  41. Pszeudókódok1 int save_context() { R0  0; SWIT { HW-PUSH(PC,PSW); PUSH (altalanos regiszterek); /* lementődött a keret, R0=0-val */ R0  (-1); JUMP Return-re; } Return(R0); } /* A HW-PUSH-nál a PC a Return-re mutat. Látjuk majd, két visszatérés van ebből. Először a JUMP Return miatt (R0=-1-gyel), másodszor a PC felvétele miatt (de akkor előtte az R0-t is felveszik, az meg 0 lesz, tehát R0=0-val). */ Vadász

  42. Pszeudókódok2 int resume_context(pid_t pid) { A pid-del azonosított processz verméről vedd vissza az általanos regisztereket; POP PSW; POP PC; /* ide a vezérlés nem juthat el */ } /* Miért nem jut oda a vezérlés? Mert a visszavett PC a save_context Return-jére mutat! */ Vadász

  43. A Context Switch pszeudókódja ... if (save_context()) { Ütemezz másik processzt, ennek pid-je = new_pid; resume_context(new_pid); /* ide a vezérlés nem juthat el */ } ... /* Innen futhat a visszavett kontextusú processz */ /* Ne feledjük, a save_context-ből két visszatérés is van: az if-nek először nem-nulla értéket ad (és belefut a schedulingba), másodszor 0-val visszatérve kikerüli azt. */ Vadász

  44. A vezérlés menete … A B IT D S Ü R 2nd IRET Dönt; if(save_context( )) { npid = Ütemez; Resume_context(npid); } 2nd; Vadász

  45. Volt már ilyen, emlékezzünk ... #include <setjmp.h> jmp_buf env; int i = 0; main () { if (setjmp(env) != 0) { (void) printf("2nd from setjmp: i=%d\n", i); exit(0); } (void) printf("1st from setjmp: i=%d\n", i); i = 1; g(); /*NOTREACHED*/ } g() { longjmp(env, 1); /*NOTREACHED*/ } Vadász

  46. Összefoglalás • Foglakoztunk az • Alapokkal, stratégiákkal • Időkiosztási algoritmusokkal • VAX/VMS, NT, Unix időkiosztással • A Context Switch implementációval Vadász

  47. OPERÁCIÓS RENDSZEREK Ütemezés és a Context Switch Vége

More Related