Operációs rendszerek 2

Átírás

1 Operációs rendszerek 2 Bringye Zsolt 2012-es előadásdiái alapján készítette: Pintér Gergő június 7. Jelen dokumentum anyaga (ábrák, táblázatok, stb.) Bringye Zsolt 2012-es előadásdiáiból származik, a diákban nem szereplő megjegyzéseket kék színnel írtam. Dokumentumverzió: v1.1 1

2 Tartalomjegyzék 1. Mi az operációs rendszer? Black-box leírás Felhasználói interfész Felhasználói csoportok Felhasználói felületek Alkalmazási Programozói Felület Hardver Interfész Interfészek, határok Operációs rendszerek fejlődése Operációs rendszer nélkül Egyszerű kötegelt feldolgozás Multiprogramozott kötegelt feldolgozás Időosztásos rendszerek Kötegelt vs. időosztásos Személyi számítógépek Valós idejű rendszerek Elosztott rendszerek PDA-k, telefonok, beágyazott rendszerek Hol a helyük? Van még tovább? Operációs rendszerek és a hardver Hardver Nincs operációs rendszer Minimál operációs rendszer A minimál OS világán túl: Multiprogramozott rendszerek Több program egyidejű futtatása Váltás programok között Védelem Operációs rendszeri szolgáltatások Multiprogramozott OS értékelése Miért hibás, késik? A méret következményei A változás mozgatórugói Unix történelem A BSD Unix Mach A Unix háború A közelmúlt Szabványok Összefoglalva Solaris példa az új Unix-ra Klasszikus (pre. SVR4) kernel A Solaris előtt Solaris 2 és azon túl A Solaris 2 kernel Konszolidáció, virtualizáció 17 2

3 6. Linux verziók Jellemzők Linux kernel Szabványos felületek Windows A Microsoft korai operációs rendszerei Roadmap Elvárások: Célok és jellemzők Kernel Folyamatok Mi a folyamat? Folyamatok állapotai Kétállapotú modell Három állapotú modell Három állapotú modell bővítés Öt állapotú modell Hét állapotú modell Valós állapot modellek (Unix) Folyamatok közötti váltás Folyamatváltás háttere Mód váltás Folyamatok létrehozása (Windows) Végrehajtható fájl Folyamatok létrehozása (Unix) Folyamat duplikálás fork() fork() másik példa Fork() működése exec() Folyamat-leírók Operációs rendszer végrehajtása Modellek Kernel kód futtatása folyamat címterében Folyamat alapú kernel Mikrokernelek miért? Hogyan is működnek az OS funkciók? Tipikus mikrokernel (alap)funkciók Mikrokernel Szálak Felhasználói szálak Signal-ok kezelése Kernel szálak Mennyire olcsó? Hibrid szálak Adatok, struktúrák További szál-megoldások? Szálműveletek

4 10.Ütemezés Folyamatok ütemezése Hosszú távú ütemezés Közép távú ütemezés Rövid távú ütemezés Algoritmusok jellemzői Folyamat megszakíthatósága (preemptive) Prioritások alkalmazása A döntés alapja Vizsgált algoritmusok összehasonlítása FCFS (FIFO) Round Robin Shortest Process Next Shortest Remaining Time Highest Response Ratio Next Feedback Lottó algoritmus Az ütemezők fejlődése Ütemezés többprocesszoros rendszerekben - szemcsézettség Folyamatok és processzorok összerendelése Kernel folyamatok és processzorok összerendelése Egyes CPU-k multiprogramozása (statikus összerendelésnél) Folyamatok és szálak ütemezése Szálak ütemezése Szálak üzemezésének módjai Valós idejű ütemezés (általános célú OS-ek esetén) Valós Idejű OS-ek jellemzői Valós idejű OS tulajdonságok Valós idejű ütemezési megoldások Ütemezési példa klasszikus Unix Folyamatok prioritása Prioritás számítása Ütemezési példa Unix SVR Mikor nem csak egy folyamat Signalok Pipe FIFO (named pipe) Üzenetsorok Osztott memória Szemaforok Memóriakezelés Áthelyezhetőség Védelem Megosztás Logikai szervezés Fizikai szervezés Memóriakezelés VM előtti idők Lapozás előtti megoldások Fix Particionálás Dinamikus particionálás Buddy algoritmus Áthelyezés kérdésköre Áthelyezési megoldás

5 12.4. Lapozás (egyszerű) Lapok összerendelése Megoldás jellemzői Szegmentálás Következmények Virtuális memóriakezelés VM működés Lapozás Szegmentálás és lapozás OS szintű kérdések Algoritmusok tervezési tér Betöltési (fetch) politika Elhelyezési (placement) politika Csere (replacement) politika Rezidens lapok kezelése Laptisztítási politika Terhelés szabályozás Windows VM kezelés Unix VM kezelés Unix lapcsere algoritmus Memória menedzsment paraméterek Swapping Kernel memória menedzsment I/O kezelés I/O eszközök jellemzői Adatátviteli sebesség Felhasználási mód (terület) További jellemzők I/O szervezés lehetőségei Operációs rendszer elvárások I/O funkciók logikai struktúrája I/O Pufferelés Egyszeres puffer Dupla puffer Cirkuláris pufferek Diszk I/O Diszkek teljesítményének elemei Idők, értékek SSD Diszk ütemezés Diszk ütemezési algoritmusok Diszk cache RAID RAID RAID RAID RAID RAID További RAID szintek Egyéb források RAID szintekről

6 15.Fájlok, fájlrendszerek Fájl menedzsment rendszer elvárások Másodlagos tároló menedzsment tervezési tere Fájlrendszer architektúra Rétegek Unix I/O (klasszikus) I/O eszközök a fájlrendszerben Unix I/O A közelmúlt (90-es évek) Unix fájlrendszerei Fájlrendszer keretek Több fájlrendszer a kezdetek Fájlrendszerek Az s5fs Berkeley FFS Speciális fájlrendszerek Tradicionális fájlrendszerek korlátai Naplózás (journaling) Egyéb témakörök Adatmentés módszerei (backup) FUSE ZFS Copy-on-write

7 1. Mi az operációs rendszer? An operating system (OS) is a computer program that manages the hardware and software resources of a computer. At the foundation of all system software, the OS performs basic tasks such as controlling and allocating memory, prioritizing system requests, controlling input and output devices, facilitating networking, and managing files. It also may provide a graphical user interface for higher level functions. It forms a platform for other software. (Wikipedia) Master control program in computer: the essential program in a computer that maintains disk files, runs applications, and handles devices such as the mouse and printer (MSN Encarta) Olyan program, amely közvetítőként működik a felhasználó és a számítógép hardvere között (Kóczy- Kondorosi, 2000) A számítógép hardver elemei és az (alkalmazói) programok közötti szoftver réteg, amely biztosítja a hardver komponensek (erőforrások) hatékony használatát. Az operációs rendszer elfedi a hardver sajátosságait, egyfajta virtuális gépként jelenik meg a felsőbb rétegek számára. Ahhoz, hogy elmagyarázzam mi a Linux, el kell magyarázzam, mi az az operációs rendszer. És az operációs rendszer meg olyan valami amivel a felhasználó sosem találkozik. Mert... valójában senki sem az operációs rendszert használja, hanem az emberek egyszerűen programokat futtatnak a gépeken. És az operációs rendszer egyetlen feladata, hogy elősegítse ezen programok futtatását. Tehát az operációs rendszer sosem csinál semmit saját magában, csak várja, hogy a programok adatokat kérjenek tőle, vagy a programok kérik, hogy egy adott fájlt a lemezről beolvasson, vagy más programokon keresztül a külvilághoz kapcsolódjon. És ekkor jön az operációs rendszer, próbálja tenni a dolgát, segítve a programozók munkáját. (Linus Torvalds, Revolution OS, felirat/fordítás: blahota@fsf.hu) 1.1. Black-box leírás Nem érdekel, mi van belül, az interfészek megadásával írom le a vizsgált valamit Felhasználói interfész Ember-gép kapcsolata, tipikus formájában képernyő, billentyűzet és (manapság) valamilyen pozicionáló eszköz segítségével. A különféle felhasználói csoportok (végfelhasználó, programozó, rendszer admin) elvárásai eltérőek, ez a különbség általában az interfészben is tapasztalható Felhasználói csoportok Végfelhasználók: Napi tevékenységükhöz szükséges alkalmazásokat használnak, operációs rendszerrel minimális a közvetlen kapcsolatuk. 7

8 Fejlesztők (alacsony szintű megoldások): Operációs rendszer által biztosított virtuális gépen fejlesztenek, operációs rendszeri eszközöket (is) használnak (utility-k). Rendszer adminisztrátorok: Operációs rendszer működését felügyelik, hangolják, folyamatos állapot információkkal kell rendelkezniük, továbbá a működésbe is beavatkoz(hat)nak Felhasználói felületek Grafikus és karakteres felületek egyaránt használatosak, egy rendszernek lehet többféle felülete is. A karakteres felület lehet parancssoros és menü alapú is. A végfelhasználók esetén szinte csak grafikus felület, de a többi csoportban is használják. Feladatok összekapcsolása sokszor hasznos lehet, ez jellemzően parancssoros megoldásoknál használatos Alkalmazási Programozói Felület Az operációs rendszer, mint virtuális gép utasításkészlete (a számítógép utasításkészletének kiterjesztése). Tipikusan rendszerhívásokon keresztül érhető el. A programozói nyelvek tipikusan elfedik ezt a felületet (még a C is hiszen itt is C függvényhívásokat, nem pedig rendszerhívásokat használunk), de a saját szolgáltatáskészletüket erre alapozzák Hardver Interfész Különféle hardver elemek kezelése: hatékonyság, hardverek sokaságának támogatása, képesség a fejlődésre (új fajta hardverek) és hibakezelés Interfészek, határok 2. Operációs rendszerek fejlődése 2.1. Operációs rendszer nélkül A kezdeti idők (40-es évek végétől az 50-es évek közepéig) teljesen manuális megoldás: kézi ütemezés (foglalási tábla) lehet, hogy programot ki kellett lőni, de az is lehet, hogy a gép üresen állt. A program indítása jelentős időt vett el a hasznos működéstől. Feladat: rendszer kihasználtságának növelése. 8

9 2.2. Egyszerű kötegelt feldolgozás 50-es évek közepe, GM (IBM platformra). A rendszer vezérlése nem manuálisan, hanem egy program által (rezidens monitor) történik, a futtatandó program kártyáit a monitornak szóló leírással (JCL) együtt előre be kellett tárazni. A megvalósítás feltételei: Memória védelem (monitor meg tudja védeni magát), időzítő (timer) később megszakítások, privilegizált utasítások (monitor megkerülése ellen) és végrehajtási módok (user, kernel) megjelenése Multiprogramozott kötegelt feldolgozás 60-as évek közepétől beszélhetünk multiprogramozott kötegelt feldolgozásról. A kötegelt feldolgozás nem segített a processzor futás közbeni üresjáratain (I/O-ra várakozás). Egy időben több program található a memóriában, ezek közül választjuk ki azt, amelyik futhat. Feltételek: memória menedzsment (több program a memóriában) illetve megszakítások Időosztásos rendszerek A kötegelt rendszerek bizonyos feladatokra (pl. tranzakció feldolgozás) alkalmatlanok, viszont a számítógépek túl drágák, hogy egyetlen ember használja őket, ezért az interaktív felhasználók (programjaik) időszeleteket kapnak. Egyik első megvalósítás: CTSS, MIT 60-évek eleje. Ide kapcsolódik a terminálok elterjedése. A computer terminal is an electronic or electromechanical hardware device that is used for entering data into, and displaying data from, a computer or a computing system. (Wikipedia, Kötegelt vs. időosztásos Kötegelt feldolgozás Időosztásos feldolgozás Optimalizálás alapja Processzor kihasználtság maximalizálása Válaszidők minimalizálása Rendszer vezérlése JCL nyelvű programok Terminálból ad-hoc módon bevitt parancsok 2.6. Személyi számítógépek Olcsó, tömegesen elterjedt rendszer, kifejezetten személyi (single user) használatra. Kezdetben korlátos erőforrások, de ma már nem. Az erőforrások kihasználása nem szempont, felhasználói élmény fokozása a cél. A felhasználók informatikai képzettsége sokkal alacsonyabb, mint a korábbi rendszereknél Valós idejű rendszerek Nem új történet, de korábban csak specializált területeken használták. Megkülönböztetünk hard és soft rendszreket, a közkedvelt rendszerek gyakorlatilag csak az utóbbi kategóriát teljesítik. Hard real-time rendszerek esetén komoly matematikai háttér Elosztott rendszerek A szükséges számítási teljesítményt és/vagy megbízhatóságot nem drága, egyedi rendszerekkel, hanem több (sok) olcsó rendszer együttműködésén alapuló megoldásokkal biztosítjuk. Igazán kényelmes használatuk újfajta operációs rendszereket (is) igényelne, ezek azonban még inkább csak kutatási fázisban találhatók meg. Feladatokat jelenleg alkalmazás és/vagy middleware szinten oldjuk meg PDA-k, telefonok, beágyazott rendszerek A klasszikus számítógépektől eltérő használati mód, eltérő hardver képességekkel (perifériák képességei, rendelkezésre álló erőforrások) jellemzik. Méret, fogyasztás sokszor kritikus. Itt is vannak operációs rendszerek: Android, ios, Windows Mobile, Linux verziók, FreeRTOS. 9

10 2.10. Hol a helyük? Van még tovább? Van, mindkét irányban, de ez már kívül esik a tantárgy tárgykörén. 3. Operációs rendszerek és a hardver Hardver Néhány szó a hardverről: Processzor Utasítások végrehajtása (utasításkészlet) Utasítások forrása: központi memória Regiszterek (általános célú, státusz és vezérlő) További adatok tárolása: központi memória Megszakítások (hardveres és szoftveres) Memória Utasítások és adatok tárolása Stack terület RAM és NVRAM (ROM) részek I/O 10

11 Típusok Másodlagos tároló Humán interfész Gép-gép kapcsolat Szélsőséges sávszélesség igények 3.1. Nincs operációs rendszer Mivel nincs operációs rendszer, így szolgáltatásokat sem nyújt a programok számára! A rendszer indításakor a program feladata az inicializálás: (Legalább részben) NVRAM-ból kell futnia, CPU beállítások (opcionális), perifériavezérlő áramkörök inicializálása. A program teljess kontrollal rendelkezik az összes hardver elem felett (beleértve a processzort is). Értékelése: Processzor, memória, I/O kezelése is teljes mértékben egyéni megvalósítás, védekezés hibás, rosszindulatú kódoktól: amit a programozó beépít, nincsenek társak (csak önmagától kell megvédenie magát). Környezet változására való érzékenység: amit a programozó beépít (jellemzően rendkívül nagy lehet) Minimál operációs rendszer Rendszer indítás és inicializálás már nem a program feladata. Minimális parancs interfész (CLI, batch), loader funkció, program lehet másodlagos tárolón vagy távoli helyen (tftp). A betöltés után a vezérlés alapvetően a programnál van. Opcionálisan: sokat használt funkciók megvalósítása (kezdetleges virtuális gép!). A perifériák kezelése tipikusan megszakítás alapon történik. Értékelése: Processzor, memória, I/O kezelése továbbra is egyéni megvalósítás, esetleg I/O esetén minimális támogatás (kb. instant eljárások). Védekezés a hibás, rosszindulatú kódoktól: amit a programozó beépít, nincsenek társak, az OS védtelen a programtól (MS DOS éra). Környezet változására való érzékenység alapvetően nagy, de mértéke az instant eljárások segítségével csökkenthető A minimál OS világán túl: Multiprogramozott rendszerek A rendszer egyetlen program általi kisajátítása nem szerencsés. Régen, mert drága volt a számítógép idő: kötegelt esetben egyetlen program általában nem tudja folyamatosan kihasználni a rendszer erőforrásait (pl. I/O-ra vár), időosztásos rendszernél a számítógépek túl drágák voltak ahhoz, hogy egy időben egyetlen ember használja őket. Ma: hatékonyság, a PC felhasználók szeretnek egyszerre több dologgal foglalkozni, a szervereknek meg egy időben több kliens kérését is ki kell, hogy szolgálják (ezért szerverek). Egy időben több kód fut (látszólag vagy valóban), a programok versenyeznek a számítógép erőforrásaiért (processzor, memória, I/O). A kódok az operációs rendszerre, egymásra és önmagukra is veszélyt jelenthetnek Több program egyidejű futtatása Kötegelt rendszerek esetén a rendszer terhelését maximalizáljuk. Interaktív rendszerek esetén a válaszidőt kell kordában tartani, a programok között periodikusan kell váltani (a felhasználók egymást nem akadályozhatják). Szerverek: itt is fontos a válaszidő, de nem közvetlen felhasználói interakcióban, hanem gép-gép szolgáltatásban, míg PC-k esetében egy felhasználó több programjára igaz Váltás programok között Programok közötti váltás: ki birtokolja a processzort? (ütemezés). A (vissza)váltás után a program a futását ott folytassa, ahol korábban abbahagyta (hasonlót már láttunk a megszakításoknál). A processzor birtoklásán túl egyéb problémák is adódnak: memóriakezelés, I/O kezelés. Memóriakezelés A processzor csak a központi memóriában található kódhoz/adathoz fér hozzá közvetlenül. A programok (adatok) folyamatos mozgatása a másodlagos tárolóról/tárolóra jelentős erőforrás és időigényt jelentene, ami alatt a processzor semmittevésre kényszerül. Egy időben több programot kell a memóriában tartani, ezért egyetlen program sem sajátíthatja ki a memóriát. A memóriamenedzsment az operációs rendszer feladata, meglehetősen összetett probléma (foglalási módok, relokáicó). 11

12 I/O kezelés Minden programnak úgy kell éreznie, hogy csak övé a gép, interferencia nem lehetséges. Az operációs rendszernek kell felügyelnie az I/O kezelést úgy, hogy a programoknak ne kelljen egymással törődniük (megosztható és nem megosztható erőforrások, nem megosztható erőforrás megoszthatóvá tétele). Ha az operációs rendszer nem eléggé szigorú, az egész rendszer hatékonysága múlhat az egyes programok jólneveltségén (pl. azonnal visszaadják-e a vezérlést, ha már nem kell nekik) Védelem Az operációs rendszernek meg kell védenie magát és a programokat egymástól. Ehhez kell a memória védelme, kontroll memória műveletek (címek) alapján és bizonyos utasítások letiltása a programnak (pl. amivel a memória védelmet lehet befolyásolni vagy perifériához hozzáférni). Ezt hardver támogatás nélkül nem lehet hatékonyan megoldani (esetleg emulációval, ami viszont lassú). Szükséges tehát memória védelmi rendszer, legalább kétféle CPU üzemmód: privilegizált az OS és normál a user kód számára (korlátozott), valamint átjárás a két mód között (szoftver megszakítások) Operációs rendszeri szolgáltatások Virtualizáció, az eredeti utasításkészlet kibővítése, elsődlegesen I/O menedzsment (most). Logikai perifériák: másodlagos tároló ( fájlok, fájlrendszerek), humán interfész (input/output csatornák), gép-gép kapcsolat. Az absztrakciós szint eltérő lehet Multiprogramozott OS értékelése Processzor, memória, I/O kezeléséhez virtualizált környezet. Védekezés hibás, rosszindulatú kódoktól azáltal, hogy a folyamatok csak a saját címterükben futhatnak (önmagukat igen, másokat nem károsíthatnak). Viszont az élet nem ennyire egyszerű: nem megfelelő (védelmi) rendszerbeállítások és a hibák végett. Környezet változására való érzékenység alapvetően az operációs rendszer szintjén jelentkezik, valós és virtuális erőforrások minél teljesebb szétválasztása. Ha az OS nem kezeli a változást, alkalmazás szintről nem (vagy nagyon nehezen) lehet rajta segíteni Miért hibás, késik? A funkciók bővülése, a támogatandó hardverek körének bővülése az operációs rendszerek komplexitásának jelentős növekedését eredményezte. Az egyik első időosztásos rendszer, a CTSS (1963, MIT) utasításból állt, az egy évvel később bemutatott OS/360 (IBM) mérete már 1 millió+ sort tartalmazott, 1975-re a Multics rendszer mérete meghaladta a 20 millió programsort. Az NT 4 mérete 16 millió+ sor, a Windows 2000 ennek több, mint kétszerese volt, míg azttől a kezdetben kicsi és egyszerű Unix mai mérete sem marad el. A Linux mérete is jelentősen növekedett a kezdetekhez képest A méret következményei Nehezen menedzselhető a fejlesztés, a kiadások jellemzően késnek, a rendszerben mindig vannak hibák, a javítások (bizonyos hibák megszüntetésén túl) nem egyszer újabb hibákat generálnak, a teljesítmény sokszor nem éri el az elvárt szintet és a rendszer sérülékeny (biztonsági fenyegetések). Ezek miatt a rendszer struktúrája fontos kérdés! A változás mozgatórugói Meglévő kód javításán, optimalizálásán túl... a funkcionalitás fájlrendszer funkciók (locking, quota, ACL) hálózati szolgáltatások snapshot (fájlrendszer) a teljesítmény, hardver fejlődése 12

13 új hardver-technológiák RAID SMP: Uniprocesszoros rendszerekben több program egyidejű futtatása látszólagos, egy időpillanatban egy aktív program van (ez lehet oprendszer kód is). Multiprocesszoros esetben valós párhuzamosság jelenik meg, ami jelentősen bonyolítja a működést. NUMA: a hagyományos memóriák elérési ideje címfüggetlen, amit ki is használunk a memória kezelő megoldásokban. A NUMA rendszerekben viszont nem. új hardver eszközök, családok támogatása teljesítmény jellemzők változása SSD: a hagyományos diszkek esetén az átvitel helyfüggő (fejmozgások), amelyekkel a különféle algoritmusok számolnak. Az SSD-k esetében nincs mozgó alkatrész. vagy abszolút változás: hálózat 10Mbit/s-ről 1Gbit/s-re (és tovább), szalagok (1999 DLT: 3MB/s, 2007 LTO-4: 120MB/s) eszközök egymáshoz képesti teljesítményének változása a minőségi elvárások, megbízhatóság adatvesztés rendszerösszeomlás esetén helyreállási idő (hiba után) működés hibák során és a paradigmaváltás, új alkalmazások kliens-szerver alkalmazások szálak real-time elvárások (pl. média szerverek) valamint a felhasználói élmény és a versenytársak jelentik a változás fő mozgatórugóit. 4. Unix történelem 1969, AT&T Bell labs: alig használt PDP-7 a sarokban áll a Multics projekt leállítása után. (Space travel játék - Thompson). A PDP-7 gépen nem volt fejlesztő környezet (cross compilert kellett használni), ezért Thompson, Ritchie és mások elkezdtek írni egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell). Multics (Multiplexed Information and Computing Service) was an influential early time-sharing operating system. The project was started in 1964 in Cambridge, Massachusetts. The last known running Multics installation was shut down on October 30, 2000, at the Canadian Department of National Defence in Halifax, Nova Scotia, Canada. (Wikipédia, Thompson, Ritchie és Ossanna meggyőzi a BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre. A Unix portolásra kerül, majd megszületnek az első egyszerű kiadvány szerkesztő programok. Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet, ennek alapján Ritchie által megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű, hogy bekövewtkezett volna, (és viszont). Bell Laboratories (also known as Bell Labs and formerly known as AT&T Bell Laboratories and Bell Telephone Laboratories) (Wikipédia, A rendszer a BTL-en belül közkedveltté válik, de házon kívül nem ismerik ban kiadott (belső) verzió már tartalmazza a cc C fordítót. Ugyanebben az évben az egész rendszert újraírják C-ben ez a lépés alapozza meg a későbbi sikert ban a Unix bemutatása egy ACM konferencián (1974, első írott publikáció). Az 1956-os antitröszt határozat miatt az AT&T nem kereskedhetett számítástechnikai termékkel (sem), ezért az ACM konferenciát 13

14 követő nagy számú megkeresés hatására az AT&T a rendszert kutatási és (egyetemi) oktatási célokra jogdíj nélkül átadta (forráskóddal együtt) ben már telepített Unix-ot találunk Kanadában, Izraelben és Ausztráliában is, a Berkeley egyetem az elsők között kap Unix licencet (1974 decemberében). A gyors terjedés mellett megkezdődnek a módosítások (forráskód elérhető), az eredményeket sokszor a BTL is beépíti saját fejlesztéseibe. A Berkeley-en különösen aktív fejlesztés folyik, az eredeti rendszert jelentősen jobbító programokat külön csomagban, pénzért (USD50) kezdik forgalmazni A BSD Unix Először itt készül virtuális memóriakezelés Unix-hoz (32 bites VAX gépre) ben pedig megjelenik az első saját OS verzió (3BSD) ez már teljes csomag. A DARPA támogatja a Unix továbbfejlesztését (VM és TCP/IP fejlesztés), ezeken kívül még több jelentős újítás is onnan származik ban megjelenik az utolsó (4.4BSD) verzió, a fejlesztés befejeződik. A rendszert a BSDI viszi tovább, a történet rögtön egy AT&T perrel indul 1994-től érhető el a 4.4BSD-lite. Azonban a fejlesztés a Bell berkein belül sem áll le, 1982-ben az AT&T beléphet a piacra. Időközben a Unix Support Group nevű csapat kiadja a System III verziót (1982), majd 1983-ban a sokkal agresszívebben marketingelt System V-t. Sok kommerciális Unix alapul valamelyik System V verzión, a jelenlei verzió az SVR4. Több cég is foglalkozott saját hardverére portolt (és kibővített) Unix forgalmazásával (ezek forrása vagy a BTL vonal, vagy a BSD volt). Az első cég Ineractive Systems 1977-ben, de a Microsoft (az SCO-val együttműködve) is az elsők között van ben Bill Joy kilép a Berkeley-ről és másokkal együtt megalakítja a Sun Microsystems céget. Rendszerük a SunOS a 4.2BSD-n alapul. A 80-as években több gyártó (IBM, HP, DEC és mások) is előrukkol saját új gépeivel és ehhez saját Unix verziót adnak ki. Minden cég megpróbál egyre több extra szolgáltatást beépíteni a rendszerébe, ez gyors fejlődést eredményez, ugyanakkor a különféle Unix verziók többé-kevésbé inkompatibilisek egymással Mach A Unix születéskori erősségei kis méret és egyszerűség az egyre több és több szolgáltatás beleintegrálásával tovatűntek. A 80-as évek elején a pittsburgi Carnegie-Mellon egyetemen megkezdődött egy új, mikrokernel alapú operációs rendszer a Mach fejlesztése. A rendszer kívülről BSD interfésszel bírt, ugyanakkor AT&T kódtól teljesen mentes volt. A 2.5-ös (még monolitikus kernelű) verzió több piaci rendszer (OSF/1 és NextStep) alapja lett, az első mikrokerneles verzió a 3.0 volt A Unix háború 1987-ben az AT&T szövetkezett a Sun-nal a következő System V verzió (SVR4) kidolgozására (a Sun korábban BSD vonalat használt). Megjelenik a Solaris 2. Ez a lépés az iparban komoly nemtetszést váltott ki, így kezdetét vette a Unix háború. Szövetségek alakultak és szűntek meg, de egy új fenyegetés a Windows NT mindent megváltoztatott A közelmúlt A Unix név és kód a Novell-hez kerül, 1993-ban a Novell a Unix márkanevet és a minősítés jogát átadja az X/Open konzorciumnak, a kódot pedig az SCO-nak, 2000-ben az üzletág a Caldera-hoz kerül, neve SCO Group lesz. Az SCO a Linux szállítókat (IBM) és felhasználókat támad szellemi tulajdon megsértéséért (a perbe a Novell is belép, végül az SCO nem jár sikerrel). A gyakorlatilag csak papíron létező SCO később (2011) az unxis kezébe kerül. Sok, a 80-as években virágzó gyártó eltűnik, a megmaradtak (IBM, HP) viszont továbbra is fejlődnek a Unix él és virul. A Sun, mint egyik meghatározó szereplő 2009-ben az Oracle kezébe került, de ennek hosszabb távú kihatásai ma még nem láthatók. A Solaris továbbra is fejlődik... (OpenSolaris, Illumos nyílt projektek) 4.3. Szabványok A sokféle verzió megkeserítette a fejlesztők életét, ezért szabványosítási törekvések kezdődtek, de szabványból is sok, különböző alakult ki (ezek nem a belső működést, hanem az interfészeket írják le). Egyik legjelentősebb szabvány az IEEE POSIX specifikáció. A szabványos kód nem tartalmazhatja az adott platformra jellemző többlet funkciókat! 14

15 4.4. Összefoglalva Kezdetben az akadémiai szektorban sikeres. Forráskód elérhetősége (feltételekkel) miatt, sok változat, ami visszahat a fő kódra is. Sok neves gyártó jelentet meg saját, üzleti alapú verziót, ez inkompatibilitáshoz vezetett, ami ellen a különféle szabványok (pl. POSIX) próbálnak védekezni. Léteznek olyan rendszerek, amelyek csak interfész szinten Unix-ok (Mach, Mac OS, Linux). Az idők során a Unix forrás is jelentősen átalakult (SVR4). 15

16 4.5. Solaris példa az új Unix-ra Klasszikus (pre. SVR4) kernel 16

17 A Solaris előtt 1982-ben megjelent a SunOS 1.0 BSD 4.1 alapú, még Motorola alapú Sun gépre, tartalmaz több hálózati technológiákat ért komoly fejlesztést, több széles körben elterjedt (NFS, RPC). Az implementálásuk jelentős módosítást igényelt, a SunOS 2.0 már tartalmazza VFS-t (1984) ban SunOS 4, új VM, dinamikus linkelés, ez az első SPARC alapú rendszer. Multiprocesszoros rendszerek támogatása, a SunOS 4.1 esetén még aszimmetrikus módon, a szimmetrikus multiprocesszing nagyon más Solaris 2 és azon túl Az AT&T szövetség hatására a Sun System V alapon teljesen új rendszerrel ál elő. Ez volt az 1992-ben megjelent Solaris 2.0 még csak uniprocesszoros, de még ebben az évben multiprocesszoros támogatás (2.1) tól megjelenik az x86 platform támogatás ban már 64 utas SMP (2.5.1), ugyanekkor fájlméret max. átlépi a 2GB-t (2.6) FS 2.2 óta nagyobb. Következő nagy lépés a Solaris 7 (nem 2.7), ami már 64 bites processzorokat is támogatja. Minden verzió hoz újításokat (RBAC, újabb ütemezők, zónák és x64 támogatás), Jelenlegi verzió az Oracle Solaris 11. OpenSolaris (Oracle felvásárlás hatásai?). Támogatott platormok: Sun UltraSPARC alapú rendszerek, Fujitsu SPARC64 platform alapú rendszerek, 32 és 64 bites AMD rendszerk és Intel valamint VIA x86 CPU-k A Solaris 2 kernel 5. Konszolidáció, virtualizáció 6. Linux Születése Linus Torvalds nevéhez kötődik, aki 1991-ben fejlesztette ki alapú gépre (az University of Helsinki hallgatójaként). A fejlesztés egy terminál emulátor szoftverrel kezdődött (Unix-os nagygépekhez való csatlakozás megoldására), de ez lett belőle... A korai verziót Linus az interneten is közzétette, hamarosan meglehetősen komoly felhasználói tábort szerezve, így a fejlesztés közösségi projektté vált. Ma sokféle disztribúció (terjesztés) létezik, egyes esetekben modifikált kernellel (aktuális stabil verzió: 3.3.7) 17

18 6.1. verziók Idővel különféle, egymással többé-kevésbé kompatibilis disztribúciók alakultak ki, ezek közül kinőtt néhány kifejezetten üzleti megoldás is. Az üzleti sikerekhez robosztusság, megfelelő funkcionalitás és gyártói támogatás szükséges. A támogatás nagy hardver és szoftver szállítóktól megvan (IBM, HP, Oracle, SAP). Fizetős disztribúciók: RedHat, SuSe, míg néhány ingyenes: Debian, Fedora és sokan mások Jellemzők A Linux jellenzői közé tartozik a POSIX kompatibilis felületek (felhasználói és programozói is), de felhasználói felületen új szabványt teremtett. A moduláris felépítésű kernel (Dynamic linking, Stackable modules), a virtuális fájlrendszer támogatás, és valós idejű ütemezés is Linux kernel Moduláris kernel (de nem mikrokernel, hanem monolitikus), fogalmi szinten sok ponton rokonságban van a Unix kernellel, de vannak különbségek (pl. szálak kialakítása). Linux esetében is megvan a kétféle mód: user és kernel mód, eltérő hozzáférési szinttel, s a kernel funkciók rendszerhívásokon keresztül érhetők el. 18

19 6.4. Szabványos felületek A szabványos felületek célja a hordozhatóság (bináris vs. forráskód szinten) biztosítása különféle gyártói megoldások között (Unix), vagy különféle disztribúciók között (Linux). A Linuxban több helyen az eredeti Unixtól élesen különböző megoldások vannak, de az interfészek szabányosak. ilyen a POSIX (Portable Operating System Interface for unix) vagy a Single UNIX Specification (The Open Group). Linux Standard Base (LSB) pedig a különféle Linux disztribúciók által minimálisan támogatandó API-k készlete révén biztosítja az egyes terjesztések közötti kompatibilitást. 7. Windows 7.1. A Microsoft korai operációs rendszerei 1981: PC-DOS 1.0 (flat FS) 1983: DOS 2.0, XT, HDD támogatás 1984: DOS 3.0, IBM AT 1990: Microsoft Windows alapú rendszerek támogatására IBM és MS közös fejlesztés (OS/2) Összeveszés, NT fejlesztés indul IBM viszi tovább az OS/2-t, ami soha nem lett átütő siker. Az OS/2 ágat viszi még tovább az ecomstation nevű zárt rendszer Roadmap A Microsoft nulláról fejleszti a saját rendszerét, amely csak felületeiben (GUI, API) hasonlít a Windows 3-ra ban az első Windows NT, a ban az NT 4.0 Win 95 felület (kernel GUI) ben Windows 2000 (plug-n-play, pwr m., AD), majd 2001-ben megjelenika Windows XP (csak desktop) ban Windows 2003 server, 64 bit (kezd. IA64). Kurrens rendszerek: Windows 2008, Win 7 (Win 8) Elvárások: 1989 Legyen 32 bites, preemptive, rendelkezzen VM támogatással. Többplatformos működés, jó SMP skálázhatóság, kliens-szerver környezet támogatás, MS-DOS és Win 3.x alkalmazások futtatása (de nem minden áron...). Kormányzati POSIX elvárás, és kormányzati biztonsági elvárások, valamint Unicode támogatás Célok és jellemzők Fejlesztési célok közé tartozik a bővíthetőség (piaci elvárások), a hordozhatóság, a megbízhatóság és a robosztusság, a kompatibilitás és a teljesítmény. Jellemzői: valós (preemptive) multitasking, kliens-szerver modell, SMP és szálak támogatása, Objektum alapú megközelítés, illetve nagyrészt C nyelvű kód. 19

20 7.5. Kernel 8. Folyamatok Programok és erőforrások dinamikus összerendelése folyamatok Tárgyalás időbeli fejlődést követ: egy processzor, nincsenek szálak; több (szimmetrikus) processzor; több szál (több processzoron), majd az operációs rendszeri megvalósítási modellek és a folyamatok és erőforrások összerendelése (CPU, memória, I/O ütemezések, együttműködés, verseny, problémák). 20

21 8.1. Mi a folyamat? A folyamat a multiprogramozott operációs rendszerek egyik alapfogalma, először a Multics rendszer fejlesztői használták (60-as években), jelentése (egyik): a program végrehajtás alatt álló példánya. A program futásához legalább az aktuálisan végrehajtandó utasításoknak és az általuk kezelt adatoknak a memóriában kell lennie. A program futása során több-kevesebb I/O eszközt szeretne használni (írni, olvasni), ezeket az operációs rendszer szolgáltatja a programoknak, ahhoz, hogy a program valóban fusson, a fenti feltételeken (memória, I/O) túl a processzorhoz is hozzáférést kell kapjon. A folyamat leírható: Terület a központi memóriában (kód, adat, stack) Adatok és státuszinformációk a processzor regisztereiben Egyéb státuszinformációk (pl. erőforrásokkal kapcsolatos) Egy végrehajtási szál (most éppen melyik utasítást kell végrehajtani) Kiindulás (most): az operációs rendszerek folyamatok szintjén ütemeznek (de már nem...). Folyamat váltáskor a teljes folyamat környezetet meg kell őrizni ez biztosítja a folytathatóságot! 21

22 8.2. Folyamatok állapotai A folyamatok és a processzorok közötti (dinamikus) összerendelésről az ütemező gondoskodik, a kiválasztást különféle ütemezési algoritmusok végzik. A hatékony ütemezés megvalósítása értekében bevezetjük a folyamatok állapotának fogalmát. A legegyszerűbb modell szerint egy folyamatnak két állapota lehet: (i) Fut, azaz éppen birtokolja a processzort, (ii) Nem fut Kétállapotú modell Kritika: Nem tudjuk, hogy az éppen nem futó folyamat tudna-e futni egyáltalán. 22

23 Három állapotú modell Kritika: Nem tudjuk, a blokkolt folyamat milyen (melyik) erőforrásra vár! 23

24 Három állapotú modell bővítés Kritika: A folyamat létrehozása és megszün- tetése nem végtelenül rövid tevékenység! Öt állapotú modell 24

25 Hét állapotú modell Valós állapot modellek (Unix) 8.3. Folyamatok közötti váltás Oka lehet az időszelet letelte (Aktív > Futásra kész), blokkolódás I/O miatt (Aktív > Blokkolt), vagy egyéb (pl. prioritások miatt). Megvalósítás (process switch) a következő lépésekből áll: az éppen futó folyamat összes 25

26 fontos adatának (környezetének) elmentése, majd a futásra kiválasztott folyamat környezetének visszaállítása és a vezérlés átadása az újonnan kiválasztott folyamatnak Folyamatváltás háttere A környezet mentés és visszaállítás minden esetben kernel kódot igényel, a váltás során általában a memória táblákat (virtuális memória kezelés) is módosítani kell. A folyamat váltás meglehetősen sok utasítás végrehajtását (CPU ciklus) igényli, ezért drága tevékenység! Mód váltás Folyamat váltás során az érintett folyamat állapota megváltozik, másik folyamat lesz aktív (futó). Bizonyos esetekben nem más folyamat, hanem a kernel kell, hogy fusson (pl. IRQ), a folyamat folytatásához szükséges adatok ilyenkor is mentendők, de ez kevesebb, mint a teljes környezet (kevésbé drága tevékenység)! Célszerű folyamat váltásról és mód váltásról külön beszélni! Kernel kód futtatása (mód váltás). Mód váltás kernel módba vált kernel által használt adatokat menti címtér nem változik, de kernel címtér elérhető folyamat tovább futhat, státusza nem változik Folyamat váltás folyamat minden adatát menteni kell címtér változik a folyamat státusza változik, más folyamat fog futni 26

27 8.4. Folyamatok létrehozása (Windows) Végrehajtható fájl Végrehajtható fájl típus Windows.exe Win16.exe MS-DOS.exe,.com,.pif MS-DOS.bat,.cmd POSIX kód OS/2 1.x kód Végrehajtás módja közvetlenül Ntvdm.exe program Ntvdm.exe program Cmd.exe Posix.exe Os2.exe 8.5. Folyamatok létrehozása (Unix) A windowsétól teljesen eltérő megoldás (eléggé fura). A program indítása két részből áll (i) az aktuális folyamat duplikálása (szülő-gyerek) és (ii) az indítandó program betöltése a gyerek folyamat helyére. Sokat kritizált, de a mai napig élő megoldás. 27

28 Folyamat duplikálás fork() mypid = fork() if(mypid == 0) { // Child printf( %ld I m the parent\n, getpid()) } else { // parent printf( %ld I m the parent\n, getpid()) } fork() másik példa int a = 1; int b = 2; if(fork() == 0) { printf( Gy:\t%d, %d\n,a,b); a += 2; printf( Gy:\t%d, %d\n,a,b); } else { printf( Sz:\t%d, %d\n,a,b); sleep(1); printf( Sz:\t%d, %d\n,a,b); } Kimenet. Gy: 1,2 Sz: 1,2 Gy: 3,2 Sz: 1, Fork() működése A fork() hatására a teljes folyamat címterét és az erőforrás adatokat is duplikáljuk. A duplikálás után a címterek függetlenek, a változók külön élnek, de a kezdőérték ugyanaz. A fájlokat mindkét folyamatból el lehet érni, ha mindkettőből írunk, akkor a kimenet összekeveredve jelenik meg exec() A fork() érdekes, de hogyan indítunk új programot? Az exec() hívás az éppen futó folyamat helyére tölt be (és indít el) egy programot, ekkor a pid nem változik és az erőforrás leírók is öröklődnek (pl. így működik a pipe a shell- ben). 28

29 8.6. Folyamat-leírók Erőforrás menedzsment megvalósításához az operációs rendszernek elegendő információval kell rendelkeznie a folyamatok és az erőforrások mindenkori állapotáról, ezt az OS különböző táblázatok fenntartásával valósítja meg. Tipikus táblázatok: memória tábla (fizikai és VM is), I/O tábla, fájl tábla és folyamat tábla. Memória tábla (fizikai és VM is) memória folyamat összerendelés, védelmi információk, VM információk I/O tábla Processz információ Státusz Memória info (pl. puffer terület) Fájl tábla Adattartalma attól függ, hogy a fájlkezelés feladatai milyen módon oszlanak meg az OS és az alkalmazás között Folyamat tábla A táblázatok függenek egymástól, de hivatkoznak egymásra (pl. fájl és I/O, folyamat és mindegyik). A táblázatokat inicializálni kell, meg kell határozni határértékeket. Ez történhet konfiguráció alapján statikusan vagy dinamikusan Operációs rendszer végrehajtása Az operációs rendszer is egy program, amelyet a CPU hajt végre, a teljes rendszer működtetéséért az OS felel, önmagát teljesen nem menedzselheti (tyúk vagy tojás), ezért operációs rendszer végrehajtási modelleket dolgoztak ki. Ilyen a nonprocess kernel, folyamat címterében futó kód és a folyamat alapú kernel Modellek A nonprocess kernel esetébn kernel szinten nem értelmezett a folyamatok fogalma, a kernel teljesen szeparált, saját törvényei szerint fut. Folyamat címterében végrehajtott kernel kód esetében a kernel nem folyamat alapú, (user) folyamatok címterében fut, minden folyamat címterében elérhető, de a folyamatok nem látják. Folyamat alapú kernel esetében a kernelt is folyamatokként valósítjuk meg (kliens-szerver modell, többprocesszoros rendszeren is hatékony), viszont kell egy folyamat váltási funkció, ami a folyamatok alatt fut. 29

30 Kernel kód futtatása folyamat címterében Folyamat alapú kernel 8.8. Mikrokernelek miért? Operációs rendszerek fejlődése alapján elkülönítjük a teljesen monolitikus kódot (több millió sor), a struktúrált felépítésű, rétegelt kódot és a mikrokerneleket. Miért nem eléggé jó a struktúrált kód? Mert a kernel módban a súlyos hibák végzetesek, nehéz kernel kódot írni és a növekvő funkcionalitás miatt egyre több és több kód kell(ene)! 30

31 8.9. Hogyan is működnek az OS funkciók? Különféle kernel funkciók pl. lapcsere memóriakezelés esetén szükséges a döntés (döntés politika), vagyis lap helyének kiválasztása és maga a végrehajtás, azaz a tényleges lapbetöltés. A végrehajtás tipikusan hardver közeli, de a döntés nem igazán, ezért ha a megfelelő adatok rendelkezésre állnak, a döntési rész akár kernelen kívül is futhat(na). Mikrokernel esetében a kernel csak az alapfunkciókat tartalmazza, a kód többi részét felhasználói módban futó szolgáltatások valósítják meg. Ezen megoldás erősségei az egységes interfész, a bővíthetőség, flexibilitás, hordozhatóság, megbízhatóság, elosztott rendszerek támogatása, és az OO támogatása Tipikus mikrokernel (alap)funkciók Alacsonyszintű memória menedzsment IPC IRQ kiszolgálás I/O kezelés (alacsony szinten) Mikrokernel Mikrokernel esetében a kernel csak az alapfunkciókat tartalmazza, a kód többi részét felhasználói módban futó szolgáltatások valósítják meg. Az igazán elterjedt rendszerekben tisztán nem igazán lehet találkozni vele. Gyenge pontok. Kernel és felhasználói mód közötti váltás erőforrás igényes (lassúság), ezért figyelni kell a kernelbe épített funkciók arányára. Ha túl sok mindent kiszervezünk, akkor sok lesz a váltással járó többletmunka. Teljesen új koncepció, gyakorlatilag nulláról újra kell írni a rendszereket. 9. Szálak Programok egyre több párhuzamosan is végrehajtható részfeladattal bírnak: szerver megoldások (web, file); kliensek esetén háttérfunkciók (backup, stb.), előtér párhuzamosítás (pl. web böngésző). A több (sok) processzor kihasználásához párhuzamosan végrehajtható kód kell!. Ezek a kódok nem függetlenek közös adatok, együttműködés (szinkronizáció)! Természetes megoldás: párhuzamos kód, ehhez több folyamat (hiszen erre való). Ez így jó (is volt sokáig), de létrehozásuk, megszüntetésük drága, a kommunikáció, együttműködés csak (drága) kernel műveletekkel lehetséges és a folyamatok közötti váltás költséges. De általában elmondható, hogy a kernel funkciók futtatása drága! Ezért van szükség a szálakra. 31

32 Az alapötlet, hogy válasszuk külön az erőforrások birtoklását a program futtatásától! A folyamat az erőforrás foglalás alapegysége (mint eddig is), a szál meg a folyamaton belüli futási végrehajtás egysége. Egy folyamaton belül egyszerre több végrehajtási szál is létezhet. A folyamathoz képest gyorsabb végrehajtás és terminálás, valamint egy folyamaton belül a szálak közötti váltás gyorsabb, mint a folyamatváltás és a szálak közötti adatcsere, kommunikáció kernel funkciók igénybe vétele nélkül zajlik. De nem a folyamatok helyett van! Megvalósítási lehetőségek: a felhasználói szálak, a kernel szálak és hibrid megoldások. 32

33 9.1. Felhasználói szálak Kernel nem tud róla, továbbra is folyamatokat lát, a szálmenedzsment alkalmazás szintű kóddal (lib) történik, így a szálütemezés folyamatonként eltérő lehet. Előnyei, hogy a szálváltás gyors (user módban fut), az OS-től független, hordozható megoldás. Korlátai, hogy a I/O blokkolhatja az összes folyamat-szálat (aszinkron I/O), 1 folyamat összes szála 1 CPU!, és a Signal-ok kezelése nem triviális Signal-ok kezelése A signalok aszinkron események (nem szinkron válasz egy hívásra). Felhasználói szálak esetén a kernel csak folyamat szinten tudja ezeket az eseményeket kezelni, így ez is a thread könyvtár problémája. 33

34 9.2. Kernel szálak A teljes szálmenedzsment kernel módban valósul meg, felhasználói szinten csak API van, tehát a szálak ütemezést a kernel végzi. Erősségei, hogy egy szál blokkolódása nem blokkolja a teljes folyamatot, a folyamat szálai több CPU-n is futhatnak és a signal kezelés megoldott, viszont korlátja, hogy drága Mennyire olcsó? 1992, VAX-on végzett mérések (UNIX-szerű környezet) UL KL Process Null fork 34 us 948 us us Signal Man 37 us 441 us 1840 us 9.3. Hibrid szálak Például Solaris-ban a Solaris 10 előtt. 34

35 A felhasználói szálak alkalmazás szinten értelmezettek, de vannak szálak kernel szinten is. A kernel LWP-k (LightWeight Process) szintjén látja a folyamatokat (ezek 1:1-ben kapcsolódnak kernel szálakhoz), az LWP-k és a felhasználói szálak közötti kapcsolatot felhasználói szintű kód menedzseli. A felhasználói szálak és LWP-k aránya dinamikus, de kódból is módosítható. A Solaris 10-ben már nincs meg ez a megoldás! Adatok, struktúrák Kell privát stack (user mindig, kernel szálak esetén kernel stack is), a szálaknak is van állapota (ready, run, blocked) és prioritása, a CPU regisztereket menteni kell: TCB (a PCB-vel analóg módon). 35

36 9.4. További szál-megoldások? Szálak Folyamatok Név 1 1 Klasszikus (multiprocessing) n 1 Több szálas (multithreading) 1 n Kísérleti (elosztott rendszerek) m n Kísérleti 9.5. Szálműveletek POSIX threads (felhasználói szintű szálkönyvtár) szolgáltatásai a szálak létrehozása és megszüntetése, az üzenetek és adatok átadása szálak között, a szálak végrehajtásának ütemezése, valamint a szál környezet mentése és visszaállítása. 10. Ütemezés 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 és rövid távú ütemezés. Ezen felül létezik még I/O ütemezés is 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, és a CPU passzív (idle) állapotának aránya a teljes CPU időhöz képest. 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 viszont 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. 36

37 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 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 viszont különböző események vezethetnek (nem mindegyik esemény érvényes minden algoritmus esetén). Ilyenek az időzítő megszakítása, az I/O megszakítások, az operációs rendszer hívások, vagy a signal-ok. Rövid távú ütemezési szempontok Meglehetősen sokféle algoritmus létezik, ám egyik sem mindenható. Lehetséges vizsgálati szempontok közé tartozik a felhasználó vagy rendszer orientált, illetve a teljesítmény alapú vagy egyéb. Felhasználó vagy rendszer orientált Felhasználó orientált esetben 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, míg az egyes felhasználók (folyamatok) kevésbé érdekesek, ez a felhasználók érdekét sértheti ezért egyszerre mindkét szempontot nem lehet teljesen kielégíteni. 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, azaz ha 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). 37

38 Szempontok Teljesítmény alapú -Fordulási idő (B) Felhasználó orientált -Válaszidő (I) -Határidők tartása -Átbocsátóképesség (B) Rendszer orientált -CPU kihasználtság B: batch (kötegelt), I: Interaktív Egyéb -Megjósolhatóság -Korrektség (Kiéheztetés) -Prioritások biztosítása -Erőforrások kihasználása Algoritmusok 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 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 A döntés alapja 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 rendsz Vizsgált algoritmusok: FCFS (FIFO), Round Robin, Shortest Process Next, Shortest Remaining Time, Highest Response Ratio Next, Feedback, Lottó ütemezéser megszakíthatja Vizsgált algoritmusok összehasonlítása Kiválasztási funkció Preemtív? Átbocsátás Válaszidő Overhead Hatása a folyamatra Kiéheztetés FCFS max[w] Nem N.a. Magas lehet Minimum Rövid és I/O igényes feladatokat bünteti Nem RR konstans Időszeletnél Alacsony, ha a Rövid folyakvantum kicsi matoknál jó Minimum Korrekt Nem SPN min[s] Nem Magas Rövid folya- Hosszú folya- Magas lehet matoknál jó matokat bünteti Lehetséges SRT min[s-e] Érkezéskor Magas Jó Magas lehet Hosszú folyamatokat bünteti Lehetséges HRRN max((w+s)/s) Nem Magas Jó Magas lehet Kiegyenlített Nem Feedback spec. Időszeletnél N.a. N.a. Magas lehet I/O igényes folyamatokat favorizálja Lehetséges 38

39 FCFS (FIFO) Működése: 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. Példa 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. Értékelés Használható általános célú ütemező, az I/O igényes folyamatokkal szemben igazságtalan, mivel az I/O igényes folyamat viszonylag gyorsan blokkolódik, így az időszelete egy részét elveszti, ezáltal ö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). 39

40 Példa 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. Példa 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), megtörténik a folyamatok felülvizsgálata, és a legrövidebb folyamat kiválasztása. 40

41 Példa (SPN, SRT) 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, hogy figyelembe veszi a folyamatok korát. Példa 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 41

42 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). Értékelése Probléma, hogy 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, így minél alacsonyabb a prioritás, annál hosszabb az időszelet. További probléma, hogy sok rövid folyamat könnyen kiéheztet egy hosszabb folyamatot, erre megoldás, az algoritmus egy módosított változata, ahol a várakozó folyamatok prioritása lassan növekszik 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, és 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, így 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, a másik pedig, hogy nehéz jó véletlen számot generálni. Az ábrán két felhasználó 6 folyamata látható, a felhasználók egyenlő arányban kapnak cpu időt, amit a folyamataik között tetszőlegesen osztanak szét (sorsjegyek). A 16 sorsjegy közül véletlenszerűen választunk és az azt bitrokló folyamaté lesz a CPU. Az ábra a táblára került föl Az ütemezők fejlődése A fejlődés mozgatórugóit a többprocesszoros rendszerek megjelenése és a valós idejű ütemezési igények megjelenése jelentette. 42

43 Ütemezés többprocesszoros rendszerekben - szemcsézettség Szemcsézettség Leírás Szinkronizálási időszak (utasítások) Finom A párhuzamosság utasítás szintű Kevesebb, mint 20 Közepes Párhuzamos feldolgozás egy folyamaton belül Durva Konkurrens, együttműködő folyamatok multiprogramozott rendszerben Nagyon durva Elosztott feldolgozás hálózaton keresztül összekapcsolt csomópontokon, amelyek közös környezetet alkotnak M Független Egymástól független folyamatok N.A Folyamatok és processzorok összerendelése Az összerendelés lehet statikus (a folyamat CPU-hoz kötött) vagy dinamikus (mindig az éppen szabad CPU-t használjuk). Az 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 Kernel folyamatok és processzorok összerendelése Kernel folyamatok CPU-hoz rendelése történhet master/slave vagy peer alapon. 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 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 Folyamatok és szálak ütemezése A tradicionális multiprocesszoros rendszerek esetén folyamat alapú ütemezés, és a folyamatokat nem kötjük hozzá processzorokhoz, jellemzően egy közös várakozósorba szervezzük őket. Mai multiprocesszoros rendszerekben az ütemezés szál alapon történik 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ó) Szálak üzemezésének módjai Terhelés megosztás Az egyprocesszoros rendszerek esetén megismert megoldást terjesztjük ki MP rendszerekre. Jellemzői: 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ányai: 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! 43

44 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. 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, és az ü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. Dedikált CPU-k A CPU-kat a folyamat élete alatt hozzárendeljük az adott folyamathoz. 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 a sok CPU-s rendszerekben (akár 100 feletti CPU számmal), egyetlen CPU a költségeknek töredékét képviseli és a folyamatváltások elmaradása a folyamat teljes futási idejére jótékonyan hathat. Dinamikus ütemezés Dinamikusan kezeljük a folyamatokhoz tartozó szálak számának változását. 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 Valós idejű ütemezés (általános célú OS-ek esetén) Egyre inkább a figyelem középpontjába kerülő problémakör, ebben az esetben a végrehajtás sikere nem csak a végeredményen, hanem annak időbeliségén is múlik. Megkülönböztetünk a Hard és Soft real time feladatokat, illetve a periodikus és nem periodikus feladatokat. Hard real-time feladatok: a határidő nem teljesítése elfogadhatatlan károkat vagy végzetes hibákat okozhat. Soft real-time: a határidő inkább elvárt, mint kötelező, megsértése esetén még mindig lehet értelme a feladat végrehajtásának. Nem periodikus feladat esetén a feladat végrehajtás kezdési vagy befejezési ideje (vagy mindkettő) kötött. Periodikus esetben adott valamiféle periódusidő. Látni kell, hogy a valós idejű rendszerek szempontjából a tervezhetőség kardinális (alapvető fontsságú)! Valós Idejű OS-ek jellemzői Megjósolhatóság: Az OS determinisztikus, ha a feladatokat fix, ismert időintervallumonként hajtja végre. A determinisztikusság meghatározza, hogy az OS mennyi időn belül tud reagálni egy megszakításra. Válaszkészség: Meghatározza, hogy az OS mennyi idő alatt hajtja végre a megszakítás kód közös részét, ez a megjósolhatósággal együttvéve vizsgálandó. Felhasználói kontroll: A rendszer finomhangolhatósága, akár egyedi folyamatok szintjén. Prioritások, VM (nem lapozható részek), diszk-kezelő algoritmusok. Megbízhatóság: Egy olyan átmeneti hiba, ami egy sima rendszernél egy reboot után megszűnik, az RT rendszernél katasztrofális lehet (mi lesz a reboot alatt?). Valamely komponens hibája (pl. CPU), ami sima rendszernél csak teljesítmény csökkenést okoz, itt az egész rendszert ellehetetlenítheti (válaszidők). Fail-soft működés: A rendszernek túl kell élnie a hibákat (akár csökkentett funkcionalitással). Tipikus (pl. Unix) rendszerekben ha a kernel hibát detektál megpróbálja a lehető legkisebb adatvesztéssel kezelni a problémát. Ennek tipikus módja a crash. fail soft: Used to describe systems that are designed to terminate any nonessential processing when there are hardware or software failures. Systems in fail soft mode are still able to provide partial operational capability. ( Valós idejű OS tulajdonságok Gyors folyamat és/vagy szálváltás Kis méret, korlátozott funkciók 44

45 Gyors reagálás a megszakításokra Multiprocessing, komoly IPC támogatás Speciális fájlok gyors adatrögzítéshez (pl. szekvenciális fájlok) Prioritás alapú, preemptiv ütemezés Megszakítások letiltásának ideje minimális Szolgáltatások folyamatok pontos késleltetésére Speciális időzítési funkciók Valós idejű ütemezési megoldások Statikus, táblázat alapú megoldások Periodikus feladatok esetén használható. Előzetes végrehajthatósági tervet készít, az ütemezés ennek alapján történik. Statikus, prioritás alapú algoritmusok A szituáció elemzése statikus, de az eredmények alapján az ütemezést hagyományos prioritás alapú ütemező végzi. Dinamikus, terv alapú megközelítés Új taszk indítása esetén az indítást csak akkor engedi, ha az újratervezett ütemezési terv alapján az időzítési elvárások tarthatók. Dinamikus, best effort működés Nem végzünk megvalósíthatósági analízist, a rendszer mindent megtesz, hogy a határidőket tartsa (de nincs rá garancia). Jelenleg elterjedten használt megoldás, nem periodikus megoldások esetén is működik Ütemezési példa klasszikus Unix A tradicionális Unix ütemezője csak a felhasználói folyamatok esetén szakítja meg a futást időzítés alapján, kernel folyamatok esetén megszakítás nem lehetséges. A Unix ütemezése prioritásos, mindig a legmagasabb prioritású folyamat fut, amennyiben azonos prioritású folyamatok találhatók a várakozósorban, közöttük az ütemező RR algoritmust használva választ. Egy folyamat prioritása egy kezdeti érték mellett előéletétől függ Folyamatok prioritása Egy folyamat prioritása egy kezdeti érték mellett előéletétől függ, minden futási állapotban töltött időszelettel csökken, és minden várakozással töltött időszelettel növekszik. Kernel funkcióból való visszatérés után a folyamat prioritása átmenetileg a felhasználói tartomány fölé emelkedik, ezzel is biztosítva, hogy az eredmény gyors elvételével a folyamat a kernel erőforrásait a csak lehető legrövidebb ideig használja. A különböző kernel funkciókhoz más-más érték tartozik, pl. a merevlemez funkcióé magasabb, mint a terminál inputot feldolgozóé. Unix esetén a folyamatok prioritása az értékükkel fordítottan arányos, pl. a 4.3BSD esetén között lehet (0 és 49 közötti rész a kernelnek van fenntartva). 45

46 Prioritás számítása Változók: p_pri: aktuális ütemezési prioritás p_usrpri: user módú prioritás (ez ált. azonos p_pri értékkel) p_cpu: CPU használat mérésére szolgál p_nice: felhasználó által megadható prioritás érték Algoritmus lépések TMR IRQ (10 msec), aktív folyamat: p_cpu = max(p_cpu+1, 127) schedcpu() rutint (1/sec), minden folyamat p_cpu értékét megszorozza A szorzó értéke SVR3 esetén fix (1 2) BSD esetén a rendszer aktuális terhelésétől függ - a terhelés növekedésével egyhez tart (kisebb, mint 1), így a folyamatok prioritásának növekedése nem gyorsul (nem úgy, mint konstans esetén). Az ütemező (1/sec) újraszámolja a folyamatok prioritását p_uspri = PUSER + (p_cpu / 4) + (2 * p_nice), PUSER=50 Kevesebb ideig futó és az I/O igényes folyamatoknak kedvez (utóbbiak sokszor várakoznak, így prioritásuk növekszik) Ütemezési példa Unix SVR4 Teljesen újradolgozták az ütemezőt, ez sem igazi RealTime, de már bizonyos időkorlátos műveleteket támogat. Statikus prioritású ütemezési osztály, 160 prioritási szint (egyes szinteken belül RR ütemezés) : RT osztály (statikus prioritás) : Kernel : Időosztásos, változó prioritású Időosztásos tartományban az időszelet prioritás függő (P0: 100 ms... P59: 10 ms). Megszakítási pontok kialakítása a kernelben, a kernel ettől nem lett tetszőlegesen megszakítható, de vannak benne olyan pontok, ahol biztonságban meg lehet szakítani az aktuális kernel funkciót. TS (timeshare): the default calss. Priorities (0-59) are dynamically adjusted in an attempt to allocate processor resources evently. IA (interactive): enhanced version of the TS class that applies to the in-focus windows in the GUI. Its intent is to give extra resources to processes associated with that specific window (range is 0-59). FSS (fair-share scheduler): This class is share-based rather that priority-based. Threads managed by FSS are scheduled based on their associated shares and the processor s utilization (range is 0-59). FX (fixed-priority): The priorities for threads associated withs this class do not vary dynamically over the lifetime of the thread (range 0-59). SYS (system): The SYS class is used to schedule kernel threads. Thread in this class are "bound" threads, which means that they run until they block or complete. Priorities are in th range. RT (real-time): Threads in the RT class are fixes-priority, with a fixed time quantum. Their priorities range Mikor nem csak egy folyamat... Korai megoldások (Unix) signal-ok pipe és FIFO Újabb eszközök (Unix, SysV IPC) 46

47 üzenetsorok (message queue) osztott memória szemaforok Az elv más rendszerekben is hasonló Signalok Aszinkron események, callback függvény jellegű megvalósítás. Legtöbbjét a kernel küldi (timer, hibák), típuson túl adatot nem közvetít, egy részük elkapható, egyesek tilthatók (de van, ami nem) Pipe Bájt alapú kommunikációt valósít meg. Nincs fájlrendszer kapcsolat, csak közeli rokon folyamatok között működik és nem perzisztens (tartósan fennálló). int fd[2];... pipe(fd); if(fork() == 0) { read(fd[0], msg, 128);... } else { write(fd[1], message, 32);... } FIFO (named pipe) Bájt alapú kommunikációt valósít meg, van fájlrendszer kapcsolat (speciális fájl), független folyamatok között is működik és perzisztens Üzenetsorok Blokk alapú kommunikáció, több-több kapcsolattal is. adható. Ez is perzisztens. Header információ (int) alapján kiválasztási szabály 47

48 11.5. Osztott memória Osztott lapok elérhetővé tétele az összes érintett folyamat címterében, hozzáférés vezérléssel Szemaforok Klasszikus szemafor implementáció: bináris szemaforok (0,1 érték) és számláló típusú szemaforok. Bináris szemafor kizárólagos hozzáféréshez, számláló típusú véges mennyiségű erőforrás menedzsmentjéhez alkalmas Memóriakezelés Az operációs rendszerek egyik legfontosabb funkciója. Az idők során különböző megoldások születtek, de a fő elvárások konkrét megoldástól függetlenül az áthelyezhetőség (relocation), a védelem (protection), a megosztás (sharing), a logikai szervezés (logical organization) és a fizikai szervezés (fizikai szervezés) Áthelyezhetőség Multiprogramozott rendszerekben a szabad memória több folyamat között oszlik meg, kevés kivételtől eltekintve a programozó nem tudhatja, hogy a program pontosan hova fog betöltődni a memóriába. A 48

49 helyzetet tovább bonyolítja, hogy a program futás közben is swapelhető, ami ismételten a memóriabeli hely megváltozásával járhat. A program futása során többször is találkozik a címzés problémájával (vezérlés átadások, adatterülethez való hozzáférés). Az áthelyezésre megfelelő választ a processzor hardvernek és az operációs rendszernek együttesen kell biztosítania Védelem Folyamatotkat védeni kell a többi folyamat véletlen vagy direkt hozzáférési próbálkozásától (kód és adatterület, írásra és olvasás). A program kódok sok esetben a következő utasítás címét is dinamikusan állapítják meg, és ez az adathozzáférésekre kiemelten igaz (lásd. Tömbök, mutatók), így védelemnek is dinamikusan, minden egyes hivatkozáskor kell működnie. Komoly hardveres támogatás szükséges (szoftverrel jelentős többletmunka). Ehhez az operációs rendszer feladata a hardver (processzor) megfelelő információkkal való ellátása Megosztás Szükséges több folyamat számára is ellenőrzött hozzáférés (írás, olvasás, futtatás) biztosítása bizonyos memóriaterületekhez, mivel ugyanazon program több példányban való futtatása helypazarló lenne és megnőne az indítási idő, illetve szükséges a folyamatok közötti együttműködés biztosítása, az osztott memória. Megvalósítása hardver támogatást igényel Logikai szervezés A számítógépek memória szervezése tipikusan lineáris, egydimenziós címterű, s ugyanez igaz a másodlagos memóriára is. A programok felépítése viszont ettől általában eltér, hiszen a programokat általában nem monolitikus tömbként kezeljük, hanem modulokból felépülő rendszernek tekintjük. A modulok egy része csak olvasható (és végrehajtható), míg más részük írható és olvasható is. Ha a memóriakezelés támogatja ezt a fajta szervezést, annak több előnye is lehet: a modulok egymástól függetlenül kezelhetők, a modulok közötti hivatkozás futási időben fordul le, továbbá a memóriavédelem modul szintű megfogalmazása magától értetődő (csak olvasható, írható-olvasható, stb.) és a memóriamegosztás szintén jól kezelhető modulok szintjén (ez az a szint, amelyen a programozó is gondolkodik) Fizikai szervezés A memória szervezése ma kétszintű. Van egy gyors és viszonylag korlátos mennyiségű elsődleges memória és lassabb, olcsóbb és sokkal nagyobb kapacitású másodlagos memória. Az elsődleges memória mérete meglehetősen korlátos (és multiprogramozott rendszerek esetén folyamatosan változó), csak a központi memória használata meglehetősen lekorlátozza a programok méretét; ezen túllépni csak programozói beavatkozással (overlay technika) lehet, amely többletmunka és igazából csak megkerüli a problémát. A legtöbb megoldás a programok számára kínált memóriát az elsődleges és a másodlagos memória valamiféle kapcsolataként hozza létre. A processzor közvetlenül továbbra is csak az elsődleges memóriához fér hozzá, így az adatok mozgatása az elsődleges és a másodlagos memóriák között az operációs rendszerek egyik legfontosabb feladata. 12. Memóriakezelés VM előtti idők Korai rendszerekben egyetlen program, memória kezelés nem volt. Az első operációs rendszerek (monitor) megjelenésével megjelent az igény a memória védelemre (OS megvédése a programoktól). Multiprogramozott rendszereknél az OS általi, valós memória menedzsment megjelenése Lapozás előtti megoldások A programok számára a kért helyet egyben, összefüggő területként foglaljuk le. algoritmusok: particionálások (fix és dinamikus), Buddy algoritmus, és szegmentálás. Az ezt lehetővé tevő 49

50 Fix Particionálás A memóriát a rendszer generálása során fix méretű és számosságú darabra osztjuk. Egy program egy ilyen darabot kap. Felvetődik a kérdés, hogy Mekkora legyen a darab? Ha kicsi, akkor a programok nem férnek el (overlay), ha nagy, akkor meg kihasználatlan, más program által nem használható helyek maradnak (belső elaprózódás). Fix particionálás alesetei Felosztás azonos méretű partíciókra, vagy eltérő méretű partíciók alkalmazása. Utóbbi, bár az előző problémákat valamelyest csökkenti, új kérdést vet föl: a partíció kiválasztásának módját. Partíció kiválasztási algoritmusok Közös várakozósor, a legkisebb szabad partíció használata. Minden programot a méretben legjobban illeszkedő várakozósorba helyezünk. Összevetés: az egyes partíciók kihasználtságára a 2. algoritmus, míg a teljes rendszer hatékonyságára az 1. algoritmus. Használat: IBM korai OS/MFT, ma már nem Dinamikus particionálás A fix particionálás gyengeségeinek áthidalására született. IBM OS/MVT által használt (Multiprogramming with variable number of tasks). Jellemzői: Dinamikus particionálás esetén a partíciók mérete és számossága dinamikusan változik, a program betöltésekor pontosan annyi memória allokálódik le a számára, amennyi a futásához szükséges, ezt azonban a programnak előre tudnia kell! Működés Üres memória esetén a program igénye alapján foglalunk le szabad blokkot a memóriából, majd újabb programok, újabb foglalás. De amikor a programok terminálnak, helyek szabadulnak fel és ezekből foglalunk. Előbb-utóbb a memória tele lesz olyan kis üres részekkel, ami már kevés egy programnak, ez a külső elaprózódás. Külső elaprózódás Előfordul, hogy nem tudunk újabb folyamatot indítani, bár a szabad memóriák összeges lehetővé tehetné. Megoldást a memória tömörítése jelenti, ez azonban meglehetősen erőforrás igényes tevékenység és azt igényli, hogy a kód futás közben is áthelyezhető legyen. Lefoglalandó terület kiválasztása First-fit: első megfelelő hely Best-fit: a lehető legjobban illeszkedő hely Next-fit: utolsó foglalást követő first-fit Tapasztalatok: legjobb a legegyszerűbb first-fit, egy kicsit gyengébb a next-fit (ez gyorsan elpazarolja a felsőbb memória részeket) és a legbonyolultabb best-fit a legrosszabb, mert a megmarandó memória darab általában túl kicsi ahhoz, hogy abból újabb kérést ki lehessen szolgálni Buddy algoritmus Fix és dinamikus particionálás korlátai közé tartozik, hogy a fix particionálás során a folyamatok száma kötött, a memóriahasználat kis hatékonyságú, valamint a dinamikus particionálás esetén az algoritmusok lényegesen bonyolultabbak és a tömörítés jelentős többletráfordítást igényel. Érdekes kompromisszum a buddy algoritmus. A memóriablokkok mérete 2L és 2U között változhat, ahol 2L a foglalható legkisebb blokkméret, és 2U pedig a memória teljes mérete. Kezdetben a teljes memória szabad, foglaláskor pedig a rendszer egy fát épít fel, 50

51 felezve a memóriablokkok méretét. Ha két egy szinten lévő blokk felszabadul, azt összevonva magasabb szintre emeljük. Buddy értékelése Általános célú algoritmusként már nem, de a mai (lapozásos) megoldásoknál sokkal egyszerűbb algoritmus. Módosított változata a mai Unix rendszerekben is megtalálható, kernel memória kezeléshez Áthelyezés kérdésköre Az eddigi algoritmusok esetén is felmerült (swap folyamat következtében, tömörítés során). Lehetséges megoldás, CPU támogatással Áthelyezési megoldás Címek (fajták) logikai cím, fizikai elhelyezkedéstől független címzés (tényleges használat előtt fizikai címre kell fordítani) relatív cím a logikai cím egy fajtája, ahol a cím egy ismert ponthoz képest relatív kerül megadásra a programban csak ilyet lehet használni! fizikai cím a memóriabeli valós (abszolút) cím. Regiszterek: Base regiszter, a folyamat futó állapotba kerülésekor állítjuk be, és Bounds regiszterek a memóriavédelemhez. A fizikai címet a CPU határozza meg, a megoldás egyben a memóriavédelmet is megvalósíthatja, hiszen a folyamat csak a bounds regisztereken belül férhet hozzá a memóriához. 51

52 12.4. Lapozás (egyszerű) Az alapötlet, hogy memóriát osszuk fel egyenlő méretű, de egy folyamat méreténél lényegesen kisebb (tipikusan néhány kilobyte méretű) lapokra. Tegyük meg ugyanezt a folyamatokkal is (azonos lapmérettel), ismét megjelenik a belső elaprózódás, de a lapméret miatt meglehetősen kis mértékben). Ezek után a folyamat lapjaihoz rendeljünk hozzá lapokat a fizikai memóriából Lapok összerendelése Folyamatos foglalás: a lapokat összefüggő módon foglaljuk a memóriában, igazából semmi extra. De a memória hozzáférés (a most vizsgált esetekben címtől független, ellentétban a NUMA-val). Ott foglaljunk lapot (egyesével), ahol éppen van üres, ez már komoly előnyökkel kecsegtet. 52

53 Megoldás jellemzői A folyamat címtere és a lapok között egyértelmű összerendelést kell biztosítani. Ez a relokációs mechanizmusba beépíthető, egy táblázat (a laptábla) segítségével minden folyamatbeli laphoz hozzárendelünk egy memória lapot. Védelem megvalósul, hisz a folyamatok csak a saját lapjaikat láthatják, a hozzáférés-kontroll (olvasás, írás) lap szintű. A címzés teljes mértékben logikai, a folyamat összefüggő címteret lát, a cím azonban (tudva azt, hogy a lapméret mindig kettő egész számú hatványa) felbontható egy lapcímre és egy lapon belüli relatív címre. A lapcím alapján a laptáblából meghatározható a lap fizikai címe, és a cím egyszerűen generálható. A címszámításhoz CPU támogatás szükséges, a laptáblák kezelése (kitöltése) az operációs rendszer feladata. 53

54 Szegmentálás A programok természetes felépítését próbáljuk követni, azaz, hogy a programot különböző méretű modulokra bontjuk (ez lehet programozói vagy fordítóprogram szintű döntés), a modulokat (szegmenseket) egymástól függetlenül kezeljük a memóriában. A szegmenseken belüli címek szintén logikai címek. A címfordítás szegmenstáblán keresztül történik (összeadással), hiszen a szegmensek mérete tetszőleges. CPU támogatás szükséges hozzá! A szegmenstábla a szegmens méretét is tartalmazza, így a hozzáférés ellenőrzése is megoldott. A szegmensméret dinamikus változtatásával a futási idejű adatfoglalás és felszabadítás is kezelhető Következmények Egyszerű lapozás és szegmentáció esetén két fontos tényező jelenik meg, az egyik, hogy a folyamatok teljes egészében logikai címzést használnak, semmiféle közvetlen kapcsolatuk nincs a fizikai memóriával (és címekkel). A másik, hogy a folyamatokat kisebb darabokra (lapokra vagy szegmensekre) osztottak, ezek egymástól függetlenül helyezkedhetnek el a memóriában (folytonos elhelyezkedés nem szükséges, sőt előnnyel sem jár). A folyamat akkor is tud futni, ha a lapjainak (vagy szegmenseknek) csak egy része található meg a memóriában. Az utasítás lefut, ha az éppen végrehajtandó kódot és az (esetlegesen) hivatkozott adatot tartalmazó memória részek elérhetők Virtuális memóriakezelés Megjelenésekor komoly viták zajlottak a megoldás hatékonyságáról. A (nem túl jelentős) teljesítmény csökkenésért cserébe jelentős előnyökkel bír: a rendszer több folyamatot tud a központi memóriában tartani, így a CPU kihasználtsága növekedhet, a program mérete túlnőhet a fizikai memória méretén, nincs szükség alkalmazás szintű trükközésekre, és ugyanaz a program különböző memóriamennyiséggel bíró gépen is futtatható újrafordítás, illetve bármilyen alkalmazás szintű törődés nélkül (úgy, hogy a több memória jótékonyan hathat a futásra) VM működés A folyamat indulásakor legalább annyi lapot vagy szegmenst be kell tölteni, amivel a futás megkezdődhet. Futás közben a CPU folyamatos címfordítást végez (logikai, fizikai), ha úgy találja, hogy valamely címhez nem tartozik terület a memóriában, úgy meghívja a megfelelő operációs rendszeri funkciót, amely gondoskodik a hiányzó lap pótlásáról. A programok a cache megoldásoknál is megismert tulajdonsága, hogy a kód futása során meglehetősen hosszú ideig limitált területen lévő utasításokat hajt végre (ciklusok, stb.), a feldolgozott adatok köre sem változik túl sűrűn, mindez biztosítja a VM létjogosultságát! Viszont hatékony hardver támogatás nélkülözhetetlen! 54

55 Lapozás Laptábla meglehetősen nagy lehet, azt a központi memóriában tároljuk (nem CPU-ban). A laptábla kezdőpontjára egy CPU regiszterre (Page table pointer) mutat. Nagy laptábla miatt, több rendszer a laptáblát magát is a virtuális memóriában tárolja (lapozható), pl. a VAX rendszereken a folyamat max. 2GB memóriát használhat, egy lap 512 byte így a laptábla maximum 2^22 darab bejegyzést tartalmazhat. Szintén elterjedt a több szintű laptábla használata, ahol az első szintű tábla mindig a fizikai memóriában van. Például 32 bites rendszeren, 4 kbyte méretű lapoknál, 4 GB címtérnél a teljes laptábla 2 20 bejegyzést tartalmaz, ami 4 Mbyte méretű, ez 2 10 lapot jelent. Ha az első szintű laptábla a fenti lapok címeit tartalmazza, akkor mérete 4 kbyte ( byte 2 10 ). Két szintű laptáblánál a címfordítás is bonyolultabb, a logikai cím három részből áll. A virtuális címtérrel arányosan növekvő laptáblák problémáját többen is próbálták megoldani, pl. UltraSPARC és az IA-64 architektúrák inverz laptábla megoldást alkalmaznak (a tábla méretét a fizikai memória határozza meg). Laptáblák miatt minden memória hivatkozáshoz legalább két hivatkozás szükséges: egy (vagy több) a címfordításhoz és egy a tényleges hozzáféréshez. A cache memóriához hasonlóan a CPU-ban a címfordítást is gyorsítják egy nagy sebességű laptábla-cache segítségével (TLB). A lapméret fontos hardvertervezési szempont, hiszen minél kisebb a lapméret, annál kisebb a belső elaprózódás, ugyanakkor növekszik a lapok száma és így a laptábla mérete. A lapok optimális méretére nincs tökéletes megoldás. Egyes processzorok változó lapméretet is támogatnak (UltraSPARC, Pentium, Itanium), azonban a mai OS-ek széleskörűen nem támogatják a változó lapméretet, bár a Solarisban van ilyen Szegmentálás és lapozás Egyesíti a két megoldás előnyét: a lapozás átlátszó módon biztosítja a memória hatékony használatát, míg a szegmentáció a program logikájának megjelenítését biztosítja a memóriakezelésben. A két módszer összekapcsolása esetén a szegmensek lapokból épülnek fel, így a memóriafoglalás egyszerűsödik (nem beszélve a méret változásáról). A logikai cím három részből áll: [Szegmens][Lap cím] [Offset]. A szegmenstábla az adott szegmenshez tartozó laptáblára mutat. Szegmentálás használatával a védelem biztosítása nyilvánvalóbb, mint lapozás esetén, kombinált esetben így a szegmentálási megoldás védelmét használhatjuk OS szintű kérdések OS memóriakezelés megvalósításának alapvető kérdései: Használ-e virtuális memóriakezelést? Lapozást, szegmentációt vagy mindkettőt használja (esetleg egyiket sem)? Milyen algoritmusokon alapul a megoldása? Az első két kérdést nem lehet megválaszolni a hardver körülmények ismerete nélkül. Például a korai Unix rendszerek nem használtak virtuális memóriakezelést (nem volt hardver támogatás hozzá). Az elmúlt időszakban néhány primitívebb rendszer, illetve néhány speciális célrendszer kivételével az összes operációs rendszer virtuális memóriakezelést használ. A tiszta szegmentáción alapuló rendszerek ritkák, a megoldások vagy lapozáson vagy pedig lapozás és szegmentáció kombinációján alapulnak. A továbbiakban a lapozás lesz a fókuszban! A CPU által megvalósított memória kezelés távol áll a teljes megoldástól, mert minden folyamatnak saját címtere van, vannak különféle védelmi és megosztási elvárások, kezelni kell a memória foglalást, felszabadítást, és a laphibákat. A memória menedzsment megvalósítása az OS feladata, ezt a hardver, mint végrehajtó segíti Algoritmusok tervezési tér Betöltési (fetch) politika, amely a lap betöltésének idejét határozza meg (első hivatkozáskor vagy előre). Elhelyezési (placement) politika, amely a betöltendő lap fizikai memóriában történő elhelyezését befolyásolja. Csere (replacement) politika, amely azt határozza meg, hogy szükség esetén melyik lapot cseréljük. 55

56 Rezidens lapok kezelésének szabályai, melyek meghatározzák, hogy egy adott folyamathoz tartozó lapokat miként kezeljük. Laptisztítási politika, amely a lapok felszabadítását, lemezre írását szabályozza. Terhelés szabályozás, amely a multiprogramozás fokát adja meg Betöltési (fetch) politika A betöltési politika kétféle lehet, igény szerinti (demand) betöltés, amiről akkor beszélünk, ha a lapot csak akkor töltjük be, amikor arra az első hivatkozás (és ezzel együtt a laphiba) bekövetkezik. Továbbá lehet előzetes (prepaging) betöltés, mely esetén nem csak a hivatkozott lapot, de az azt követő néhány lapot is betöltjük, mert feltételezzük, hogy a program azt is használja majd. Ez a módszer a laphibák számát próbálja csökkenteni, illetve a lassú diszk miatti várakozás idejét próbálja leszorítani, annak árán, hogy esetleg feleslegesen betöltött lapokkal foglalja le a memóriát Elhelyezési (placement) politika A politika azt határozza meg, hogy a memória mely részére töltsük be a lapot. A legtöbb rendszer esetén a memóriakezelés módja (eltérően pl. a diszkektől) helyfüggetlen, úgyhogy e politika nem releváns. Fontos kivételt jelentenek a NUMA architektúrák, melyek esetén a memóriához való hozzáférés sebessége függ attól, hogy saját memóriáról vagy távoli memóriáról van szó Csere (replacement) politika Az eldobandó lap kiválasztásának szabályait adja meg. Legfontosabb alapalgoritmusok: optimális, legutoljára használt (Last recenty used), FIFO, és óra (Clock). Optimális algoritmus Az optimális algoritmus azt a lapot választja ki eldobásra, amelyre a rendszerben a lapok közül legkésőbben fogunk hivatkozni. Ez az algoritmus jövőbeli információra épít, azaz ilyen nem létezik! A valós algoritmusoknak a rendszer múltbeli viselkedése alapján kell megjósolnia a jövőt. Ez az algoritmus jó összehasonlítási alap. A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések. 56

57 Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor. LRU, FIFO algoritmus Az LRU algoritmus a lapok használati mintájára épít, csere esetén a legrégebben használt lapot dobja el, arra gondolnak, hogy ezt a lapot fogjuk legkisebb valószínűséggel használni.az algoritmus megvalósítása nem triviális, a lapokhoz olyan információt kell rendelni, amely alapján meghatározható a lapok utolsó használatának sorrendje. A FIFO algoritmus a lapok betöltési ideje alapján választja ki az eldobandó lapot. Ezt az információt sokkal könnyebb nyilvántartani, mint az utolsó használat idejét, így ennek az algoritmusnak a megvalósítása sokkal egyszerűbb, mint az LRU-é. LRU algoritmus (vég) ábrája A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések. Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor. 57

58 FIFO algoritmus (vég) ábrája Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor. Clock algoritmus A cél az LRU algoritmushoz hasonlóan hatékony, de annál sokkal olcsóbb algoritmus létrehozása. Az óra algoritmus ilyen-olyan verziójával több operációs rendszerben is találkozhatunk. Az algoritmus működéséhez minden laphoz hozzá kell rendelni egy használati bitet. Mikor a lapot betöltjük a memóriába, a lap használati bitjét 1-es értékre állítjuk, és lapra való hivatkozás esetén a lap használati bitjét szintén 1-re kell állítani. A lapokat körkörös pufferbe szervezzük, melyhez hozzárendelünk egy mutatót (a körkörös pointer-lista az óra számlapja, a mutató pedig az ami). Lapcsere igény esetén a mutató körbejár, hogy nullás használati bittel rendelkező lapot keressen, s a lapokon átlépve (ha a használati bit egyes értékű volt), a használati bitet nullázza. Ha a mutató körbeér, akkor megáll a kezdőlapnál (ahonnan idul), és azt cseréli le. Egy lap cseréje után a mutató a kicserélt utáni lapra mutat. Clock algoritmus - kiindulás, majd feltöltés A kék mező értéke 0, a zöldé meg 1. 58

59 59

60 Clock algoritmus 5. lap hivatkozás, nincs hely ezért nullázás 60

61 Clock algoritmus - példák más elrendezésekre Egy konkrét példa laphibák szemléltetésére A narancs mező jelzi a laphibát, a narancs keret pedig azt, ami helyére betöltjük, az oszlopk pedig az egyes lépések. 61

62 Az ábra a végállapotot mutatja, az egyes lépéseket nem tettem bele, lásd eredeti diasor. Összehasonlító táblázat Az egyes algoritmusok által okozott laphibák számának szemléltesére. Page Buffering Problémák: az LRU és a Clock jobbak a FIFO-nál, de költségesebbek, egy nem változott lap eldobása sokkal olcsóbb, mint egy módosítotté. Megoldási próbálkozás: page buffering, jelentős megoldás VAX/VMS rendszerben. FIFO algoritmus, de nem dobja el rögtön a lapot, hanem lista végére írja, így a szabad lapok listája (nem változott), de változott lapok listája. Ha a lapra hivatkoznak, visszaszedhető a listáról. Először a szabad lapok listájáról próbál lapot osztani (tartalma ekkor veszik el igazából), és a változott lapokat kötegelve írja ki, így kisebb az I/O terhelés Rezidens lapok kezelése Virtuális memóriakezelés esetén nem szükséges a folyamathoz tartozó összes lapnak a memóriában lennie (hiszen erről szól az egész), egy adott folyamat esetén az egyidejűleg szükséges lapok számának meghatározása politikai döntéseken (is) múlik. A folyamathoz tartozó lapok számának hatásai: Minél kevesebb lapot rendelünk egy folyamathoz, annál több marad a többi folyamatnak, azaz több folyamatot tudunk egyszerre futtatni. A folyamatokhoz rendelt lapok számának csökkentésével a laphibák száma egyre több lesz. A folyamatokhoz rendelt lapok számának növelése egy ideig csökkenti a laphibák számát, azonban egy határon túli növelése már nem vezet észrevehető javuláshoz. A fenti szempontok egymásnak ellentmondanak, tökéletes (minden helyzetre egyaránt megfelelő) megoldás nincs. A rezidens lapkezelés szempontjai: 62

63 Lapkészlet mérete: egy folyamathoz rendelt lapok száma a futás során állandó, vagy változhat. Lapcsere hatásköre: lapcsere során az operációs rendszer csak a laphibát okozó folyamat lapját veheti el, vagy az összes lap közül választhat. Fix lapszám Változó lapszám Lokális csere Globális csere A folyamathoz rendelt lapok száma álandó Lapcserénél az eldobandó lap Nem lehetséges a folyamat saját lapjai közül A folyamathoz rendelt lapok Lapok száma változhat száma időről időre változhat Lapcserénél az eldobandó lap bárme- Lapcserénél az eldobandó lap lyik memórialap lehet, függetlenül attól, a folyamat saját lapjai közü hogy az melyik folyamathoz tartozik Fix lapszám, lokális csere A folyamathoz rendelt lapok száma állandó, laphiba esetén az operációs rendszer az eldobandó lapot csak a folyamatok saját lapjai közül választhatja ki. Egy adott folyamathoz rendelt lapkészlet méretét a futás megkezdésekor meg kell határozni, ez történhet automatikusan (az indítandó program fajtája alapján), de kérelmezheti az indítandó program is. Ez a fajta foglalási megoldás kétélű, ugyanis ha a rendszer túl sok lapot foglal le a folyamathoz, akkor a lapok egy része kihasználatlan, ami globálisan szemlélve a teljes rendszer teljesítményét rontja (kevesebb folyamat futhat). Ha viszont túl kevés lapot rendelünk a folyamathoz, akkor folyamatos laphibákkal kell szembenézni, amely egyrészt rossz a folyamatnak (lassan fut), ugyanakkor a sok laphiba a rendszert is leterheli. Változó lapszám, lokális csere A lapcsere mindig a folyamat saját lapjaiból történik, azonban a rendszer periodikusan felülvizsgálja, és szükség esetén növeli vagy csökkenti a folyamathoz rendelt lapkészlet méretét. A folyamatok ebben az esetben a fix/lokális esethez hasonlóan meghatározott méretű készlettel indulnak, és ennek a készletnek a mérete a periodikus felülvizsgálat során változhat (a folyamat laphasználási szokásainak függvényében). Ez a megoldás meglehetősen jó teljesítményt biztosíthat, azonban sok múlik a lapkészlet méretét szabályozó algoritmuson. Változó lapszám, globális csere Ennek a politikának az implementálása a legegyszerűbb, több operációs rendszeri megvalósításban is találkozhatunk vele. Az operációs rendszer általában fenntart egy listát néhány szabad lappal, laphiba esetén erről a listáról emel le egy szabad lapot. laphiba esetén a folyamat által birtokolt lapok száma nő, probléma a lapok a folyamattól történő elvételekor lépnek föl. Amennyiben a szabad lapok száma nullára (vagy egy limit alá) csökken, valamely folyamattól lapot kell elvenni, ebben viszont bármelyik folyamat érintett lehet. E megoldás esetén jelentős teljesítmény javulást lehet elérni az ún. page buffering eljárás segítségével, mely esetében a folyamattól visszavett lapokat nem szabadítjuk fel azonnal Laptisztítási politika A laptisztítási politika a betöltési politika ellentéte, azt határozza meg, hogy lapok felszabadítása igény esetén (ha laphiba lép fel) történjék (on-demand), vagy mindig tartsunk néhány szabad lapot a rendszerben (precleaning). Gyengeségek: Előzetes laptisztás esetén olyan lapot is felszabadítunk, amire rövidesen ismét szükség lesz, azaz ezzel növeljük a laphibák számát. Igény szerinti laptisztítás esetén viszont a laphibák kezelése lesz hosszadalmas (hiszen ilyenkor esetleg ki is kell írni az eldobandó lap tartalmát a másodlagos tárolóra). A page buffering algoritmus ezen a problémán is segít, hiszen ebben az esetben egy, a közelmúltban felszabadított lapra történő hivatkozás esetén a lap könnyen visszanyerhető. 63

64 Terhelés szabályozás Memóriában található folyamatok számának korlátok közé szorítása: túl kevés folyamat esetén a rendszer kihasználtsága lesz alacsony, túl sok folyamat esetén pedig a laphibák száma emelkedik túlzottan magasra. Rendszer kihasználtsága a folyamatok számának tükrében: a folyamatok számának növelésével eleinte javul a rendszer kihasználtsága, egy maximum érték után viszont a görbe csökkenni kezd. A folyamatszám további növelésének következménye a trashing jelenség, mikor a CPU idejét folyamatosan a laphibák kezelését szolgáló kód futtatásával tölti. Ha a terhelés meghaladja az optimális értéket, az operációs rendszernek néhány folyamat futását fel kell függesztenie (suspension), és a teljes folyamatot (minden lap) a másodlagos tárolóra másolnia. Felfüggesztendő folyamat(ok) kiválasztása A felfüggesztendő folyamat(ok) kiválasztása különböző szabályok alapján történhet: legalacsonyabb prioritású folyamatok kiválasztása, laphibát okozó folyamatok, mert valószínű, hogy ezek újabb laphibákat fognak előidézni, a legutoljára indított folyamat, mert valószínűleg ez még nem töltötte be a futásához szükséges összes lapot, legkevesebb lapot birtokoló folyamat, mert ennek mentése és visszatöltése a legolcsóbb, legtöbb lapot birtokló folyamat, mert ennek felszabadítása eredményezi a legnagyobb javulást a rendszer állapotában. Minden mindennel összefügg Az operációs rendszerek esetén nincs elsőbbség a modulok között, azok gyakran összefonódnak egymással. Virtuális memóriakezeléshez a diszken foglalunk helyet a lapoknak, ugyanakkor a diszkműveletek gyorsításához a központi memóriában foglalunk le helyet cache célra, valamint a multiprocesszoros rendszerekben a folyamatok tetszőleges CPU-n való futtatása a kihasználtságot javítja, de a CPU-k TLB-ének hatékonyságát rontja, stb Windows VM kezelés A Windows kezdettől fogva virtuális memóriakezelésen alapuló rendszer, lapmérete változó lehet, de platform szinten fix. 32 bites verzió esetén a 4 GB-s címtér felét a felhasználói folyamatok használhatták, felét pedig a rendszer. Voltak próbálkozások a 4 GB felosztás átalakítására (bizonyos verziókban), de a 64 bites rendszerek megjelenése miatt effajta trükközésre nincs szükséges. A Windows rezidens lapkezelése változó lapszámú, de lokális cserével működik Unix VM kezelés A Unix rendszerek memóriakezelése az OS története során sokat változott. A kezdeti változó particionálást alkalmazó megoldásokat felváltották a virtuális memórián alapuló technikák. Kezdetben (és még nagyon sokáig) a kernel által használt memória statikusan volt lefoglalva a modern Unix verziók esetében már a kernel is használ memória menedzsment megoldást, igaz nem a lapozást. A folyamatok és a buffer cache kezelése lapozáson alapuló virtuális memóriakezeléssel történik, a kernel folyamatosan fenntart valamennyi szabad lapot, amiből kielégíti a folyamatok lapfoglalási igényeit. Ha a szabad lapok száma egy meghatározott szint alá csökken, a kernel elkezd lapokat visszavenni a folyamatoktól Unix lapcsere algoritmus A lapcsere algoritmus a clock algoritmus finomított változata, két mutatóval. Az első mutató körbeforogva nullázza a használati biteket, de a lapok kiválasztását a második mutató végzi, így ha közben a lapot használják, úgy annak használati bitje ismét egy lesz. Az algoritmust két paraméter jellemzi: (i) a mutatók forgási sebessége, és (ii) a fáziseltolás a két mutató között. 64

65 Memória menedzsment paraméterek A paraméterek kernel konfigurációjától, a fizikai memória mennyiségétől függenek. Név Leírás lostrfree desfree minfree slowscan fastscan scan rate Swapping Amennyiben a rendszerben a szabad lapok száma ezen érték alá csökken, a rendszer megkezdi lapok felszabadítását A rendszerben található lapok elvárt értéke A szabad memória legalacsonyabb, még elfogadható szintje. Ha a szabad lapok száma ezen érték alá csökken a memória felszabadítás drasztikusabb lesz Másodpercenként átvizsgálandó lapok számának minimuma (scan rate) Másodpercenként átvizsgálandó lapok számának maximuma (scan rate) Rendszer dinamikusan számolja, slowscan < sr < fastscan Soft swapping: ha a rendszerben a szabad lapok elmúlt 30 másodperces átlaga a desfree érték alatt volt, a kernel inaktív folyamatokat keres és azokat teljesen eltávolítja a memóriából (swap). Hard swapping: több feltételnek is teljesülnie kell, amelyek azt jelzik, hogy a rendszer komoly memóriagondokkal küzd (szabad lapok száma, lapcsere aktivitás foka, stb.). Ebben az esetben a kernel nem használt modulokat és aktív folyamatokat is swap-elhet. A swapping rendkívül erőforrás igényes, megjelenése kerülendő (memória bővítés)! Kernel memória menedzsment A kernel memóriaigényét a buddy algoritmuson alapuló megoldás elégíti ki, mely lazy buddy névre hallgat. A buddy algoritmus működése során a blokkok szétosztása és összevonása erőforrás igényes, a kernel esetében (a használat jellege miatt) gyakori hogy egy éppen összevont blokkot kell szétosztani. A lazy buddy algoritmus ezért nem egyesíti rögtön a blokkokat, hanem a lehető legkésőbbig próbálja kitolni ezt a feladatot, akkor viszont a lehető legtöbb blokkot egyszerre egyesíti. 13. I/O kezelés I/O eszközök csoportosítása Csoportosítás kapcsolódás fajtája szerint: Felhasználói kapcsolat (bevitel és kivitel is) Gép általi kapcsolat (pl. HDD, tape) Kommunikáció (gép-gép közötti) A fenti csoportokba tartozó eszközök között is jelentős eltérések lehetnek, ezért további jellemzők vizsgálata szükséges! I/O eszközök jellemzői 1. Adatátviteli sebesség (Data rate) 2. Felhasználási terület (Application) 3. Vezérlés összetettsége (Complexity of control) 4. Adatátvitel egysége (Unit of transfer) 5. Adatok megjelenése (Data representation) 6. Hibalehetőségek (Error conditions) 65

66 Adatátviteli sebesség Különféle eszközök átviteli sebessége között több nagyságrendi eltérés is lehet, és a sávszélesség nem köthető a kapcsolat fajtájához! Billentyűzet kevesebb, mint 100 bit/sec Ethernet: 10 9 bit/sec. Eszköz Átviteli sebesség (10 n bit/sec) Giga ethernet 9 Grafikus megjelenítő 10 (PCI Express) HDD 9 (Seagate: 78 MB/s) Felhasználási mód (terület) Az eszköz felhasználási területe befolyásolja, hogy az operációs rendszernek milyen módon kell azt kezelnie. Például a lemezegységek használatához általában fájlkezelő rendszer szükséges, azonban ha a lemezegységet a memória lapok tárolására használjuk (másodlagos memória) a fájlkezelés helyett másfajta lemezkezelésre lesz szükség További jellemzők Vezérlés összetettsége: egy mátrixnyomtató kezelése viszonylag egyszerű feladatot ró az operációs rendszerre, ugyanakkor egy lemezegység kezelése meglehetősen összetett feladat. Az átvitel egysége: adatokat bájtok vagy karakterek folyamaként is átvihetjük, de kezelhetjük az adatokat összefüggő blokkokban is. Az adatok megjelenése: különböző eszközök az adatokat más-más kódolásban igényelhetik (karakterkódok, paritás, stb.). Hibalehetőségek: hibák jellege, a hibajelentés módja, és a hiba fellépése esetén elvégzendő intézkedések fajtáji eszközről-eszközre változnak. A változatosság ellenére azt várjuk, hogy az operációs rendszer az I/O kezelést egységes, eszközfüggetlen interfészen keresztül biztosítsa számunkra I/O szervezés lehetőségei I/O kezelési technikák Programozott I/O Megszakítás vezérelt I/O DMA alapú I/O Az I/O funkciók fejlődése A processzor direkt vezérli az eszközöket Kontroller (I/O modul) hardver hozzáadása Megszakítások kezelése (I/O modul) DMA megjelenése Az I/O modul egy programozható célprocesszorként jelenik meg. A központi CPU feladata a programkód megadása és a folyamat indítása (I/O csatorna) Az I/O processzor nem a központi memóriát használja, hanem dedikált memóriával rendelkezik Operációs rendszer elvárások Hatékonyság: az I/O eszközök többsége a CPU-hoz képest lassú, ezért az I/O kezelő funkciókat úgy kell elkészíteni, hogy a lassú eszköz miatti várakozás során más folyamat futhasson. Ma már léteznek olyan gyors perifériák, amelyek kiszolgálása jelentős teljesítmény-optimalizálást igényel. Általánosság: sokszínűségük ellenére egységes periféria-kezelési megoldás mind OS szintjén (belső struktúrák), mind a folyamatok felé nyújtott interfészen (read, write, open, close, lock, unlock) keresztül. A megoldást a hierarchikus struktúrák alkalmazása jelenti. 66

67 13.4. I/O funkciók logikai struktúrája Klasszikus megoldás: hierarchikus megközelítés, az egyes rétegek csak a saját feladatukért felelnek. Logikai I/O feladata az általános I/O funkciók szolgáltatása a folyamatok felé, az eszköz I/O feladata az I/O kérések lefordítása eszköz specifikus parancs-szekvenciákra, és az ütemezés, vezérlés feladata pedig az I/O műveletek sorba állítása, ütemezés (pl. IRQ-k kezelése) I/O Pufferelés Ha az eszközök közvetlenül csatoltak a folyamathoz, akkor az érintett memória lapok nem lapozhatók, a művelet befejeztéig a folyamatnak várnia kell (az adott terület nem módosítható), és a beviteli műveletek esetén csak az igény szerinti (on- demand) működés képzelhető el. Pufferelésnél egy kernel területén található átmeneti tár közbeiktatásával szétválasztjuk az eszközt és a folyamatot. Pufferelési módok: egyszeres puffer, dupla puffer és cirkuláris pufferek Egyszeres puffer A műveletek egy kernel pufferbe/ből történnek, a kernel-user címtér utáni mozgatás után a puffer felszabadul (kezdődhet a következő művelet). A user címtér lapozható, de ekkor a memória menedzsment elbonyolódik Dupla puffer Két puffert használunk, az egyiket az OS, a másikat a user folyamat fogja. Két művelet történhet egy időben, ez gyorsabb, mint az egyszeres, de bonyolultabb is Cirkuláris pufferek A dupla pufferelés továbbgondolása, a kernel n puffert rendel egy folyamathoz, ez bizonyos esetekben tovább gyorsít. A megoldás a termelők-fogyasztók modellel írható le. 67

68 The consumer producer problem (also known as the bounded-buffer problem) is a classical example of a multi-process synchronization problem. The problem describes two processes, the producer and the consumer, who share a common, fixed-size buffer used as a queue. The producer s job is to generate a piece of data, put it into the buffer and start again. At the same time, the consumer is consuming the data (i.e., removing it from the buffer) one piece at a time. The problem is to make sure that the producer won t try to add data into the buffer if it s full and that the consumer won t try to remove data from an empty buffer. (Wikipédia, További magyar nyelvű leírás a problémáről itt: hz/pdf-tamop/pdf-03/html/ch05.html 14. Diszk I/O Probléma, hogy a diszk és CPU/Mem közötti sebesség különbség folyamatosan növekedett az elmúlt időben (és valószínűleg ez így is marad), a diszkek több nagyságrenddel lassabbak a CPU-nál. Mivel a leggyakoribb I/O művelet a diszkekkel kapcsolatos (fájl, VM) a diszkkezelés hatékonysága alapvető fontosságú az operációs rendszerek számára Diszkek teljesítményének elemei Seek time: a fej mozgásának ideje (megfelelő track fölé). Forgási késleltetés: amíg a track-on belül a kívánt blokk befordul. Átviteli idő: a konkért írás vagy olvasás. A seek time és a forgási késleltetés összege adja az elérési időt. A fenti időkön túl még számolni kell az eszközre való várakozás idejével és az I/O csatornára való várakozás ideje (ha az osztott) Idők, értékek Seek time A fej mozgásához szükséges idő. Ez a mozgás nem teljesen lineáris. A mai kisebb diszkek esetén rövidebb, mint a régi nagyobb (pl. 14 inch) lemezeknél. Mai jellemző érték ms. Forgási késleltetés A lemez forgási sebességétől függ, mai HDD-k esetén a és a közötti percenkénti fordulatszám a jellemző (a csak a low-end, hordozható eszközökben), 15k esetén egy teljes fordulat ideje 4ms, így az átlag 2ms! Átviteli idő Szintén a fordulatszám függvénye. Egy track-en belül számítható: T = b/(rn), ahol b az átviendő bájtok, r a forgási sebesség, és N a track mérete bájtban. Példadiszk átlagos seek idő: 4ms fordulatszám: (full: 4 ms) szektorméret: 512 byte szektor/track: 500 (16 us) Feladat: 2500 szektor (1.28 MB) beolvasása. 1. megoldás: összefüggő elhelyezkedés 5 track 68

69 (a) 1. track: seek + forgás rekord olvasása = 10 ms (b) track: 4x(forgás + olvasás) /no seek/ = 24 ms (c) Összesen: 34 ms 2. megoldás: véletlenszerű elhelyezkedés Tanulságok (a) 2500 x (átlagos seek + átl. Forgás + olvasás) (b) 2500 x (4m+2m+16u) = 14.6s! (c) Összesen: 14.6 s 34 msec vs sec (nagyságrendi eltérés) Fájlrendszereket célszerű úgy szervezni, hogy a fájlok elhelyezkedése ne legyen teljesen véletlenszerű! Multiprogramozott rendszerek esetén az egymástól független I/O műveletek esetén érdemes optimalizációt végezni! SSD Új, ígéretes, drága, saját problémákkal. A HDD-hez képest rendkívül rövid késleltetés (latency), lassabb írás és olvasás, nagyon lassú törlés (kötelező), és Wear-out, azaz egy adott terület csak véges számú alkalommal írható (kb írás) jellemzi. Forrás: SSD esetén a tulajdonképpeni olvasás lassabb, de a késleltetés nagyon kicsi. Írás esetén a törlést is figyelembe kell venni, ami viszont rendkívüli mértékben visszafog! Mit jelent ez? SSD hatékony használata új megoldásokat kíván a hagyományos diszkekhez képest: flash specifikus fájlrendszerek, speciális Flash driver-ek. Hol használjuk (jelenleg)? Hordozható fogyasztói eszközök (pl. kamerák), laptop HDD-k, gyorsító megoldás adatbázis rendszerekben és enterprise kategóriájú rendszerekben (pl. Sun 7xxx sorozatú Unified Storage rendszerek) Diszk ütemezés A következőkben tárgyaltak alapvetően a hagyományos merevlemezekre igazak! Diszk kérések hatékony kiszolgálására multiprogramozott rendszerekben tökéletes megoldás nincs. Tárgyalt algoritmusok: FIFO, prioritásos, LIFO, SSTF, scan (és változatai). 69

70 Diszk ütemezési algoritmusok FIFO: kiszolgálás a beérkezés sorrendjében, korrekt ütemezés, kevés számú folyamatnál hatékony is lehet, sok folyamatnál viszont a hatékonysága drasztikusan romlik. Prioritásos: mindig a legnagyobb prioritású kérést, emiatt kiéheztetés lehetséges. LIFO: Mindig a legfrissebb kérést szolgálja ki, filozófiája lényege, hogy az utolsó kérés az előző közelében lehet, így gyorsan kiszolgálható. Sok folyamatnál ez nem feltétlenül igaz, kiéheztetés itt is lehetséges. SSTF: mindig a legrövidebb kiszolgálási időt igénylő (legkisebb fejmozgás) tartozó kérést szolgálja ki, a megoldás nem garantálja, a fejmozgások globális minimumát. Kiéheztetés itt is lehetséges. Scan: Cél a hatékonyság növelése a a kiéheztetést elkerülése mellett (ezt eddig csak a FIFO oldotta meg). A fej fel-le mozog, és minden útjába akadó kérést kiszolgál. A középső részeket favorizálja, és tömeges kérésekkel leragasztható. C-Scan: mindig csak egy irányba megy, a Scan első problémáját megoldja. N-step-Scan: a diszk sort N nagyságú részekre osztja, egyszerre csak egy N-est dolgoz fel. FSCAN: két sor van, amíg az egyikből dolgozik, a kérések a másikba gyűlnek, e két megoldás a leragadást oldja meg Diszk cache Gyorsítótár, a gyorsítótáraknál korábban megismert célokkal és problémákkal. Gyorsítótár: központi memória (drágább, kisebb kapacitású, de gyorsabb, mint a merevlemez), algoritmusok: gyorsítótár lehető legoptimálisabb használata. Diszk cache tervezési kérdések Gyorsítás iránya : csak olvasáskor (write through), vagy mindkét irányban (write back). Memória felhasználás módja: fix (előre meghatározott), vagy dinamikus (terheléstől függő). Adat átadás a cache-területről (olvasáskor): másolás a felhasználói címtérbe, vagy sztott memória használata. Blokkcsere algoritmusa: LRU (least recently used), LFU (least frequently used), vagy frequency-based RAID Diszk (másodlagos tároló) problémák: teljesítményük növekedési rátája szignifikánsabban alacsonyabb a CPU növekedésnél, 70

71 a tárolt adatok fontossága miatt a nagy kapacitású diszkek hibája egyre nagyobb üzleti kockázattal járt, a nagy kapacitású diszkek sem eléggé nagyok. RAID koncepciója: nagy kapacitású és teljesítményű drága diszkek helyett kisebb (olcsóbb) diszkeket használva érjük el célunkat, azaz a kapacitás növelését, a teljesítmény növelését és a megbízhatóság növelése. Az elnevezés a Berkley egyetem kutatóitól származik (1988), akkor ők ezt a Redundant array of Inexpensive Disks szavakból állították össze. A névben később az Inexpensive szó Independent -re változott... Dióhéjban, úgy kapcsolunk össze több diszket, hogy az operációs rendszer számára egy diszknek látszanak, az adatot szétosztjuk a diszkek között, és a diszk hibák ellen paritás információ tárolásával védekezzünk (ezt két megoldás nem elégíti ki). A szabvány 5+1 szintet definiál, a +1 nem redundáns és 3 terjedt el, de a különböző gyártók további szinteket is definiálnak, valamint szint-kombinációkat is alkalmazunk. A különböző megoldások a szükséges tárolóterület overhead-ben, a megoldás teljesítményigényében és a biztonság szintjében térnek el. RAID szintek RAID-0 (striping) Redundancia nélküli megoldás. RAID-1 (tükrözés) Adatduplikáláson alapul (nem paritás alapú). RAID-2 Speciális, Hamming kód alapú Gyakorlatilag kihalt. RAID-3 Kizáró vagy műveletre épít, egy blokk az összes diszkre szét van osztva Erős hardver támogatást igényel! RAID-4 Kizáró vagy műveletre épít, egy blokk csak egy diszken található Dedikált paritás diszket használ. RAID-5 Hasonló a RAID-4 megoldáshoz, de itt a paritás is szét van osztva a diszkek között. Háttér információk A diszkek átviteli jellemzőjének tényezői a mechanikai működésből adódó késleltetés, és az adatátvitel végrehajtásának teljesítménye (átviteli sebesség). A terhelés jellege lehet kevés számú, kis párhuzamosságú, de nagy mennyiségű adatot mozgató terhelése (pl. kötegelt feldolgozás), vagy nagy számú, magas párhuzamosságú, de kicsi adatmennyiséget érintő terhelés (tranzakciós rendszerek). Kapcsolat a fentiek között a nagy mennyiségű adatot mozgató terhelésnél az adatátvitel teljesítménye domináns, míg nagy tranzakciószámnál a késleltetések sokkal fontosabbak. Olvasás és írás műveletek különbsége redundáns tároláskor abban jelentkezik, hogy olvasáskor csak annyi adatot kell beolvasni, ami elegendő a kért adatblokk biztosításához, míf íráskor az adatblokkhoz tartozó összes részt aktualizálni kell. Ezért vizsgáljuk a tárolás módjár és a viselkedést íráskor illetve olvasáskor. A példákban a diszkek száma N, egy diszk átviteli sebessége pedig T RAID-0 Tárolás módja Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. Redundancia nincs a rendszerben. Hasznos terület: N. Olvasás Egy időben ~N független olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: T. Hiba esetén: működésképtelen! 71

72 Írás Egy időben ~N független írása tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: T. Hiba esetén: működésképtelen! RAID-1 Tárolás módja Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. A redundanciát a teljes adat duplikálása eredményezi. Tipikusan N=2, hasznos terület: N/2. Olvasás Egy időben ~N független olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: T. Hiba esetén: egy időben ~(N-1) független olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: T. Írás Egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: =< T. Hiba esetén: Egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: =< T RAID-3 Tárolás módja Byte szintű csíkok, a blokkok az összes diszkre szét vannak osztva. Byte szintű paritás képzés XOR művelettel történik, a megoldás dedikált paritás diszket használ. N>2, hasznos terület: N-1. Olvasás Egy időben 1 olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: (N-1)*T. Hiba esetén: egy időben 1 olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: < (N-1)*T (számolni kell). Írás Egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: <= (N-1)*T (számolni is kell). Hiba esetén: egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: <= (N-1)*T (számolni is kell). 72

73 RAID-4 Tárolás módja Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. Blokk szintű paritás képzés XOR művelettel történik, a megoldás dedikált paritás diszket használ. N>2, hasznos terület: N-1. Olvasás Írás Egy időben (N-1) független olvasási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség: T. Hiba esetén: az olvasási tranzakciók száma akár egyre is lecsökkenhet, mert a hibás diszkeken található adatok előállításához az összes többi diszkblokk adata szükséges! Egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség < < T. Egy blokk kiírása után a teljes sor paritását újra kell számolni. Hiba esetén: 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség < < T RAID-5 Tárolás módja Nagyméretű csíkok, egy blokk egyetlen diszken tárolódik. Blokk szintű paritás képzés XOR művelettel történik, a paritás blokkok is szét vannak osztva a diszkek között. N>2, hasznos terület: N-1. Olvasás Egy időben (N-1)...(N) független olvasási tranzakció. 73

74 Írás Tranzakciónkénti átviteli sebesség: T. Hiba esetén: az olvasási tranzakciók száma akár egyre is lecsökkenhet, mert a hibás diszkeken található adatok előállításához az összes többi diszkblokk adata szükséges! Egy időben 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség < < T. Hiba esetén: 1 írási tranzakció szolgálható ki. Tranzakciónkénti átviteli sebesség < < T További RAID szintek Raid-6 Két paritás blokk használatával (n+2 konfig) nagyobb hibatűrést biztosít, Az írás során jelentős overhead, Nem igazán terjedt el. Raid-S EMC Symmetrix diszktömbökben használt technológia, Raid-5 szerű, de speciális, teljesítményt növelő eljárásokat alkalmaz. Kombinált Raid: 1+0 és : összetükrözi a stripe-ot. 1+0: tükröket stripe-ol Egyéb források RAID szintekről RAID0,1,3,5,10: RAID0,1,5,10: (angol) RAID0,1,2,3,4,5,6,01,10: (magyar) RAID0,1,3,5,01,10: (angol) 15. Fájlok, fájlrendszerek Felhasználói szempontból az operációs rendszer (egyik) legfontosabb része, mert ezzel közvetlen találkozik, a fájlok tárolása, hozzáférés alapvető, és a teljesítmény szempontjából kritikus. Alapvető elvárások Hosszú távú tárolás: A fájlokat másodlagos tárolón (tipikusan merevlemezen) tároljuk, ahol fájlok tartalma a felhasználó kilépése, a gép kikapcsolását követően is megmarad. Megoszthatóság: Ugyanazt azt az adathalmazt több program is elérhesse, a fájlok egyértelmű azonosítása alapvető és amennyiben igényelt, a fájlokat több felhasználó is elérhesse. Strukturáltság: A fájlok tartalmát (adatokat) jól ismert struktúrába kell szervezni, valamint a fájlok között is célszerű struktúrát definiálni (sok fájl, átláthatóság). Tipikus fájl műveletek Az általános modellban létrehozás, törlés, megnyitás, lezárás, olvasás és írás van, de az egyes konkrét implementációk további műveleteket is definiálhatnak. 74

75 Fájl struktúrák A struktúra-elemei: mező, alapelem Rekord, összetartozó mezők gyűjteménye Fájl, összetartozó rekordok Adatbázis, összetartozó fájlok Mai rendszerekben a struktúra meglehetősen egyszerű, az összetett(ebb) adatstruktúrák kezelését alkalmazás szintű komponensekre bízzák Fájl menedzsment rendszer elvárások Felhasználók (és alkalmazások) adattárolási, adatkezelési igényeinek kielégítése, Tárolt adatok validitásának biztosítása, Teljesítmény optimalizálás rendszer (globális) és felhasználói szempontból egyaránt, Különféle tároló eszközök támogatása, Adatvesztés kockázatának minimalizálása, Szabványos (programozói) interfész biztosítása, Többfelhasználós működés támogatása Másodlagos tároló menedzsment tervezési tere Fájl foglalása Előzetes foglalás: a létrehozáskor lefoglaljuk (fix méret) Dinamikus foglalás Foglalási egység változó hosszú, összefüggő: nagyon jó teljesítmény, módosítás és felszabadítás problémás blokk alapú: fix méretű (kicsi) blokkokból foglalunk. Bonyolultabb nyilvántartás, rosszabb teljesítmény, viszont könnyen módosítható és újrahasználható Fájl foglalási módszerek (blokkos) Folyamatos foglalás Láncolt foglalás (minden blokk külön) Indexelt foglalás (minden blokk külön) Szabad hely nyilvántartása Bit tábla használata Láncolás Indexelés Szabad blokkok listája (külön területen, a diszken tárolva) 75

76 15.3. Fájlrendszer architektúra Rétegek Device driver: kommunikáció a különféle hardver elemekkel (eszközfüggő). Basic FS (physical I/O): alacsony (blokk) szintű műveletek. Basic I/O supervisor: I/O sorbaállítás, ütemezés. Logical I/O: magas szintű file műveletek. File szervezés: NEM Unix/Win világban Pile ( struktúrálatlan, ahogy jön) Szekvenciális (rekord alapú) Indexelt szekvenciális (rekord alapú) Indexelt (rekord alapú) Direct (hash) fájlok (rekord alapú) 76