1 / 47

Operációs Rendszerek II.

Operációs Rendszerek II. 6. előadás 2007. március 12. Folyamatok ütemezése. A folyamat ütemezés célja a folyamatok és a processzor(ok) összerendelésének dinamikus szabályozása. Típusai: Hosszú távú ütemezés Közép távú ütemezés Rövid távú ütemezés Ezen felül létezik még I/O ütemezés is.

whitley
Download Presentation

Operációs Rendszerek II.

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 II. 6. előadás 2007. március 12.

  2. Folyamatok ütemezése • A folyamat ütemezés célja a folyamatok és a processzor(ok) összerendelésének dinamikus szabályozása. Típusai: • Hosszú távú ütemezés • Közép távú ütemezés • Rövid távú ütemezés • Ezen felül létezik még I/O ütemezés is A mai nap a folyamat ütemezésről szól, I/O ütemezés később!

  3. Hosszú távú ütemezés • A programok aktiválását szabályozza (folyamat diagramban a „felvesz” állapot átmenetet jelképezi). • Biztosítja, hogy a multiprogramozás foka optimális legyen a rendszerben. Szempontok: • folyamatok száma a rendszerben • a CPU passzív (idle) állapotának aránya a teljes CPU időhöz képest

  4. Megvalósítás • Kötegelt rendszerek esetén a job-ok egy várakozó sorba kerülnek, ebből választ a hosszú távú ütemező. A döntés dimenziói: • Mikor válasszon új folyamatot: multiprogramozás fokának optimalizálása • Melyik folyamatot válassza: FIFO vagy terhelési minta optimalizálás. • Interaktív rendszerekben a felhasználó a fő ütemező, OS lehetőségei: ha a rendszer terhelése meghalad egy kritikus szintet (ez általában a folyamatok számában, esetleg a szabad virtuális memória mennyiségében mérhető), akkor nem engedi új folyamat létrehozását.

  5. Közép távú ütemezés • Feladata komplett folyamatok mozgatása a központi memória és a másodlagos tároló (swap terület) között (swapping). • Vizsgálata a memóriakezelés ismertetése során fog megtörténni

  6. Rövid távú ütemezés • Ez az ütemező közvetlenül és folyamatosan meghatározza a processzor(ok) és a folyamatok közötti kapcsolatot. • A hosszú- és közép távú ütemezők viszonylag ritkán aktivizálódnak csak durva ütemezési döntéseket hoznak. • A rövid távú ütemező aktivizálódásához különböző események vezethetnek (nem mindegyik esemény érvényes minden algoritmus esetén): • Időzítő megszakítása • I/O megszakítások • Operációs rendszer hívások • Signal-ok

  7. Rövid távú ütemezési szempontok • Meglehetősen sokféle algoritmus létezik, egyik sem „mindenható”. • Lehetséges vizsgálati szempontok: • felhasználó vagy rendszer orientált • teljesítmény alapú vagy „egyéb”

  8. Felhasználó vagy rendszer orientált • Felhasználó orientált eset • az egyedi felhasználók (folyamatok) igényeit vesszük figyelembe, így például az egyes folyamatok válaszidejét. • Ezek azok a szempontok, melyeket interaktív rendszer esetén egy felhasználó valóban érzékel. • Rendszer szempontjából • a rendszernek a kihasználtsági szint maximalizálására kell törekednie • az egyes felhasználók (folyamatok) kevésbé érdekesek, – ez a felhasználók érdekét sértheti • Egyszerre mindkét szempontot nem lehet teljesen kielégíteni.

  9. Teljesítmény alapú vagy egyéb • A közvetlen teljesítmény jellemzők mellett más tényezők is befolyásolják a rendszerről alkotott véleményt, pl: • megjósolhatóság: folyamatosan hasonló válaszidőket produkáló rendszer sokkal inkább elfogadható egy felhasználó számára, mint egy folyamatosan ingadozó rendszer (ugyanarra a tevékenységre vizsgálva)

  10. Szempontok B: batch (kötegelt, I: Interaktív

  11. Algoritumusok jellemzői • Folyamat megszakíthatósága • Prioritások alkalmazása • A döntés alapja (amely alapján meghatározzuk a kiválasztandó folyamatot)

  12. Algoritumusok jellemzői • Folyamat megszakíthatósága (preemptive) • Meghatározza, hogy az ütemező algoritmus megszakíthatja-e egy folyamat futását, vagy az csak akkor szakad meg, ha a folyamat lemond a CPU-ról vagy erőforrás miatt blokkolódik. • A megszakítható ütemező algoritmusok általában bonyolultabbak, jobban terhelik a rendszert – ugyanakkor sokkal korrektebb ütemezési megoldást biztosítanak.

  13. Algoritumusok jellemzői • Folyamat megszakíthatósága • Prioritások alkalmazása • Több olyan algoritmus is van, ahol a folyamatok közötti választást egy, a felhasználó által meghatározott fontossági információ (prioritás) befolyásolja. • A „tiszta” prioritásos megoldás fő problémája az alacsonyabb prioritású folyamatok kiéheztetése.

  14. Algoritumusok jellemzői • Folyamat megszakíthatósága • Prioritások alkalmazása • A döntés alapja több paraméter közül kerülhet kiválasztásra: • A folyamat rendszerben eddig eltöltött összes ideje (várakozás és végrehajtás egyaránt): w • Az eddig futással eltöltött idő: e • A folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s • Fontos látni, hogy a kiszolgálási idő valóban csak becsülhető – amely az esetleges múltbéli tapasztalatok alapján pontosítható. A túlzottan optimista folyamatok futását (amelyek az előre megadottnál sokkal tovább kívánnak futni) a megadott idő letelte után a rendszer megszakíthatja.

  15. Vizsgált algoritmusok • FCFS (FIFO) • Round Robin • Shortest Process Next • Shortest Remaining Time • Highest Response Ratio Next • Feedback • Lottó ütemezés

  16. FCFS (FIFO) • Működés • A legegyszerűbb algoritmus, amely beérkezésük sorrendjében futtatja a folyamatokat. • Az algoritmus nem megszakítható, ha valamely folyamat blokkolódik, helyette a legrégebben a sorban található folyamat kerül kiválasztásra. • Értékelés • Az algoritmus előnybe részesíti a CPU igényes folyamatokat, hiszen azok sokkal ritkábban blokkolódnak, mint az I/O igényes folyamatok. • Az algoritmus következtében az I/O eszközök kihasználtsága meglehetősen rossz.

  17. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  18. Példa – FCFS (FIFO)

  19. Round Robin • Az interaktív rendszerek alapalgoritmusa. Az időzítő periodikusan megszakításokat generál, a kernel minden megszakításkor másik folyamatot választ ki futásra a futásra kész folyamatok közül – így alapesetben minden folyamat egy időszeletnyi ideig futhat. • Az algoritmus egyik alapvető kérdése az időszelet hosszának meghatározása. • Nagyon rövid időszelet választásával a rövid folyamatok gyorsan végrehajtásra kerülnek, ugyanakkor a sok folyamatváltás komoly többletterhet ró a rendszerre. • Legcélszerűbb olyan időszeletet választani, amely egy tipikus interakció végrehajtását lehetővé teszi – ez a megoldás kifejezetten jó hatással van a válaszidőre.

  20. Round Robin (értékelés) • Használható általános célú ütemező • I/O igényes folyamatokkal szemben igazságtalan • az I/O igényes folyamat viszonylag gyorsan blokkolódik, így az időszelete egy részét elveszti • összességében a CPU igényes folyamatok sokkal több időt kapnak, mint az I/O igényes társaik. • Módosított algoritmus a fenti probléma megoldására • a várakozósor két sorból áll: az egyik „normál” várakozósoron kívül van egy sor a blokkolásból visszatérő folyamatok számára is. • Amíg a második sor nem üres, a kernel ebből választ folyamatot – azonban ez a folyamat csak a blokkoláskori időszeletéből megmaradt időtartamig futhat (ezután – ha nem blokkolódik ismét – visszakerül a normál várakozósorba).

  21. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  22. Példa – Round Robin

  23. Shortest Process Next • Az ütemező mindig azt a folyamatot választja, amelynek legrövidebb a becsült teljes kiszolgálási ideje • Rövid folyamatokat favorizálja a hosszabbakkal szemben • Nem megszakítható algoritmus

  24. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  25. Shortest Remaining Time • Az SPN egy megszakítható változatának tekinthető • Mindig az a folyamat lesz futásra kiválasztva, amelynek legkisebb a várható futási időszükséglete (tehát ami még hátra van) • Amennyiben folyamat kerül a várakozósorba (pl. blokkolódásból visszatér), a megtörténik a folyamatok felülvizsgálata, és a legrövidebb folyamat kiválasztása

  26. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  27. Példa – SPN, SRT

  28. Highest Response Ratio Next • Célja a fordulási idő és az aktív idő (mikor a folyamat valóban futott) arányának minimalizálása. • (nem megszakítható módon) mindig azt a folyamatot választja ki, amely esetében az R=(w+s)/s hányados értéke a legnagyobb. • w a rendszerben eltöltött összes idő, s pedig a becsült teljes kiszolgálási idő. • Előnye: figyelembe veszi a folyamatok korát

  29. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  30. Példa – HRRN

  31. Feedback • Az előző algoritmusok közös problémája az, hogy alkalmazásukhoz legalább becsléssel kell rendelkeznünk az adott folyamat várható futási idejéről – ez pedig sok esetben nem lehetséges. • A feedback algoritmus az ütemezési döntést a folyamat eddigi „élete” alapján hozza meg. • Az algoritmus megszakítható, időszelet alapú azonban változtatható prioritásokat használ: • minél hosszabb ideje fut a folyamat a rendszerben, annál jobban csökken a prioritása (egy minimum értékig).

  32. Feedback (értékelés) • Probléma: az algoritmus a hosszú folyamatokat komolyan bünteti • Megoldás: különböző prioritási szintek esetén eltérő időszeleteket használ: minél alacsonyabb a prioritás, annál hosszabb az időszelet • Probléma: sok rövid folyamat könnyen kiéheztet egy hosszabb folyamatot • Megoldás: az algoritmus módosított változatában a várakozó folyamatok prioritása lassan növekszik

  33. Vizsgált algoritmusok Folyamat rendszerben eddig eltöltött összes ideje: w Az eddig futással eltöltött idő: e Folyamat becsült teljes kiszolgálási ideje (az eddig eltöltött időt is beleértve): s

  34. Lottó algoritmus • A klasszikus változó prioritásos ütemezők problémáit próbálja kiküszöbölni: • nem lehet a folyamatoknak CPU birtoklási arányt megadni • egy felhasználó monopolizálhatja a rendszert ha sok folyamatot indít • Minden folyamat adott számú (sors)jegyet kap, az ütemezés „véletlen” sorshúzással zajlik. A folyamatok CPU birtoklási aránya a kapott jegyek számán alapul • Ha a jegyeket a felhasználóhoz rendeljük, akkor az összes folyamata számára adunk birtoklási arányt – nem lehet monopolizálni a rendszert • A megoldás egyik komoly hátránya az, hogy a blokkolás miatt elveszett idő-töredékek valóban elvesznek – erre az algoritmus továbbfejlesztése ad megoldást

  35. Az ütemezők fejlődése • A fejlődés mozgatórugói • Többprocesszoros rendszerek megjelenése • Valós idejű ütemezési igények megjelenése

  36. Ütemezés többprocesszoros rendszerekben - szemcsézettség

  37. Folyamatok és processzorok összerendelése • Az összerendelés lehet • Statikus (a folyamat CPU-hoz kötött) • Dinamikus (mindig az éppen szabad CPU-t használjuk) • SMP megoldások esetén a statikus összerendelés jelentős teljesítmény problémákat okozhat (bár sokkal egyszerűbb megvalósítani) • az egyik CPU várakozósorában több folyamat várakozik, míg egy másik CPU kihasználatlanul várakozik.

  38. Kernel folyamatok és processzorok összerendelése • Kernel folyamatok CPU-hoz rendelése történhet • master/slave • peer • Master/slave esetben a kernel kulcsfunkcióit valamely CPU-hoz kapcsoljuk. • Ez a megoldás jelentősen leegyszerűsíti a működést, de ez a CPU könnyen szűk keresztmetszetté válhat. • Teljesen dinamikus működés esetén viszont arról kell gondoskodni, hogy ha a két CPU egyszerre aktivizálja valamely kernel funkciót, akkor nehogy ütközés legyen.

  39. Egyes CPU-k multiprogramozása (statikus összerendelésnél) • Elvben lehetséges, de… • Ha sok CPU van a rendszerben 1-1 CPU kihasználtsága nem igazán fontos • Sok esetben a szálak akkor tudnak igazán hatékonyan futni, ha egyszerre aktívak (egyéb esetben a közöttük fellépő szinkronizációs igény jelentősen visszaveti a működést). • Előfordulhat, hogy több szál együttes futása fontosabb, mint minden CPU folytonos kihajtása.

  40. Folyamatok és szálak ütemezése • A tradicionális multiproc. rendszerek • Folyamat alapú ütemezés • Folyamatokat nem kötjük hozzá processzorokhoz, jellemzően egy közös várakozósorba szervezzük őket • Mai multiprocesszoros rendszerek • Ütemezés szál alapon történik

  41. Szálak ütemezése • Egyprocesszoros rendszerekben a szálakat a programozás megkönnyítésére használták • Többprocesszoros rendszerekben a szálak már a valós párhuzamosság kihasználására is alkalmasak • Ebben az esetben azonban fontos lehet, hogy a párhuzamos szálak valóban egy időben fussanak (kommunikáció).

  42. Szálak üzemezésének módjai • Terhelés megosztás: az egyprocesszoros rendszerek esetén megismert megoldást terjesztjük ki MP rendszerekre • Csoportos ütemezés, a szálak és a CPU-k között 1:1 megfelelést alakítunk ki, a folyamat futásához pontosan annyi CPU kell, amennyi szála van • Dedikált CPU-k, a CPU-kat a folyamat élete alatt hozzárendeljük az adott folyamathoz • Dinamikus ütemezés, dinamikusan kezeljük a folyamatokhoz tartozó szálak számának változását

  43. Terhelés megosztás • Jellemzők • Terhelést egyenlően osztjuk szét a CPU-k között • Nincs szükség központi ütemezésre, minden szabad CPU magának választ folyamatot • Ehhez kell egy globális folyamat-sor • Hátrányok • A folyamat-sor szűk keresztmetszet lehet, bár ez a probléma több tíz, sőt több száz CPU esetén jelentkezik • A szálak nem biztos, hogy az előzőleg kiválasztott CPU-hoz térnek vissza, ami lokális gyorsítótárral rendelkező CPU-k esetében problématikus • Több szálból álló folyamat esetén nem valószínű, hogy az összes szál egyszerre aktivizálódik – ez pedig a szál szinkronizáció során teljesítmény probléma. • Hátrányai ellenére ez a legelterjedtebb ütemezési mód!

  44. Csoportos ütemezés • Több (egy folyamathoz tartozó) szál együttes kiválasztásának előnyei • a szorosan kapcsolódó szálak szinkronizáció miatti blokkolódásának problémája jelentősen csökken • ütemezési terhelés többlet kisebb, hiszen egy döntés több CPU-t is érint • Ehhez az ütemezéshez szükséges valamilyen CPU foglalási algoritmus

  45. Dedikált CPU hozzárendelés • A csoportos ütemezésnek egy extrém formája. • Látszólag rendkívül CPU pazarlóan működik (hisz nincs CPU szintű multiprogramozás), bizonyos esetekben megoldás lehet • Sok CPU-s rendszerekben (akár 100 feletti CPU számmal), egyetlen CPU a költségeknek töredékét képviseli • A folyamatváltások elmaradása a folyamat teljes futási idejére jótékonyan hathat

  46. Dinamikus ütemezés • Sok esetben a folyamathoz tartozó szálak számossága folyamatosan változhat, így a statikus összerendelések nem túl hatékonyak • Ezek az algoritmusok általában az operációs rendszerek és a folyamatok közötti együttműködést igénylik • Az operációs rendszer feladata a CPU-k szétosztása a folyamatok között, a többi már a folyamat szint feladata

More Related