Operációs Rendszerek II. 8. előadás március 25.

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, a fő elvárások konkrét megoldástól függetlenek: –Áthelyezhetőség (relocation) –Védelem (protection) –Megosztás (sharing) –Logikai szervezés (logical organization) –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 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) – védelemnek is dinamikusan, minden egyes hivatkozáskor kell működnie. •Komoly hardveres támogatás szükséges (sw overhead). –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 •Okok –ugyanazon program több példányban való futtatása (helypazarlás, indítási idő) –Folyamatok közötti együttműködés biztosítása, 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ű. –Ugyanez igaz a másodlagos memóriára is. •A programok felépítése ettől általában eltér, –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 –A memóriavédelem modul szintű megfogalmazása magától értetődő (csak olvasható, írható-olvasható, stb.) –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ű: –gyors és viszonylag korlátos mennyiségű elsődleges memória –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á. –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.

Memóriakezelés – 1 „VM előtti idők” •Korai rendszerekben egyetlen program, memória kezelés nem volt •Az első operációs rendszerek (monitor) megjelenése: igény a memória védelemre (OS megvédése a programoktól) •Multiprogramozott rendszerek: 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 –Szegmentálás

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” •Mekkora legyen a darab? –„Kicsi”: a programok „nem férnek el” (overlay) –„Nagy”: 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 •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 hoz: –Partíció kiválasztásának módja

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: •Egyes partíciók kihasználtsága : 2. alg. •Teljes rendszer hatékonysága: 1. alg. Használat: IBM korai OS/MFT, ma már nem

Dinamikus particionálás •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 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 –Újabb programok, újabb foglalás •De: programok terminálnak, helyek szabadulnak fel – ezekből foglalunk –Előbb-utóbb a memória tele lesz olyan kis üres részekkel, ami már kevés egy programnak – 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 –igényli, hogy a kód futás közben is áthelyezhető legyen

OS, 8M Free 56M 56/56M OS, 8M 36M P1, 20M 36/36M OS, 8M 22M P1, 20M P2, 14M 22/22M OS, 8M 4M P1, 20M P2, 14M P3, 18M 4/4M OS, 8M 4M P1, 20M 14M P3, 18M 18/14M P4, 8M OS, 8M 4M P1, 20M 6M P3, 18M 10/6M P4, 8M OS, 8M 4M 20M 6M P3, 18M 30/20M Start (OS: 8M) -P1: 20M -P2: 14M -P3: 18M -P2: exit -P4: 8M -P1: exit -P5: 24M

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) –Legbonyolultabb „best-fit” a legrosszabb, 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: –a fix particionálás során a folyamatok száma kötött, a memóriahasználat kis hatékonyságú –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

Buddy algoritmus •A memóriablokkok mérete 2 L és 2 U között változhat, ahol –2 L foglalható legkisebb blokkméret –2 U pedig a memória teljes mérete •Kezdetben a teljes memória szabad, foglaláskor pedig a rendszer egy fát épít fel – felezve a memóriablokkok méretét •Ha két egy szinten lévő blokk felszabadul, azt összevonva magasabb szintre emeljük

Start1M R100k512k256k128kA R64k512k256kAB kCAB 6464 R240k 512kCAB 6464 R256kD Rel B256kA128k Rel A512k D D -A: 128k -B: 64k -C: 256k -D: 256k -C: out -B: out -A: out

Buddy értékelés •Általános célú algoritmusként már nem… •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ül –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 –„Bounds” regiszterek: memóriavédelem •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.

program adat stack Base reg Bounds reg Összeadó Ellenőr Relatív cím

Lapozás (egyszerű) •Alapötlet: 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  NUMA) –Ott foglaljunk lapot (egyesével), ahol éppen van üres –ez már komoly előnyökkel kecsegtet

Page noStartLoad ALoad BLoad CTerm BLoad D 4 pgs3 pgs4 pgs-5 pgs 0FreeA.0 1FreeA.1 2FreeA.2 3FreeA.3 4Free B.0 FreeD.0 5Free B.1 FreeD.1 6Free B.2 FreeD.2 7Free C.0 8Free C.1 9Free C.2 10Free C.3 11Free D.3 12Free D.4 13Free

•A folyamat címtere és a lapok között egyértelmű összerendelést kell •Relokációs mechanizmusba beépíthető –Egy táblázat – laptábla – segítségével minden folyamatbeli laphoz hozzárendelünk egy memória lapot Megoldás jellemzői Page no.offset Logikai cím Laptábla Fizikai cím

Megoldás jellemzői •Védelem: a folyamatok csak a saját lapjaikat láthatják •A hozzáférés-kontroll (olvas, ír) 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

Szegmentálás •A programok természetes felépítését próbáljuk követni – azaz a folyamat memóriáját nem egyben, hanem modulonként (szegmensenként) foglaljuk •A szegmenseken belüli címek szintén logikai címek, itt azonban a címszámítás már összeadással jár – hiszen a szegmensek mérete tetszőleges – CPU támogatás szükséges! •A szegmensek megoldják a védelmet is (az egyes szegmensek méretét a CPU ismeri)

Címszámítás - szegmentálás Logikai cím Fizikai cím Szegmens tábla Seg.offset

Következmények •Egyszerű lapozás és szegmentáció esetén két fontos tényező jelenik meg: –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 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).

Következmények •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

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ök: –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 –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: 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 – ez biztosítja a VM létjogosultságát! •Hatékony hardver támogatás nélkülözhetetlen!

Visszatekintés - 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 regiszter (Page table ptr) 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 –Pl. 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 (2 12 – 4 byte x 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.

Visszatekintés - Lapozás •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 –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), a mai OS-ek széleskörűen nem támogatják a változó lapméretet (pl. Solarisban van ilyen)