Operációs Rendszerek II. 5. előadás

Operációs Rendszerek II. 5. előadás

Sunday, March 21, 2010

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!


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 222 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 220 bejegyzést tartalmaz, ami 4 Mbyte méretű – ez 210 lapot jelent. Ha az első szintű laptábla a fenti lapok címeit tartalmazza, akkor mérete 4 kbyte (212 – 4 byte x 210). Két szintű laptáblánál a címfordítás is bonyolultabb, a logikai cím három részből áll. Sunday, March 21, 2010

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)


Szegmentálás • A programot különböző méretű modulokra bontjuk (ez lehet programozói vagy fordítóprogram szintű döntés), a modulokat egymástól függetlenül kezeljük a memóriában. • A címfordítás szegmenstáblán keresztül történik (összeadással) • 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ő.


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?


OS szintű kérdések • 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!


Miért ez az egész? • A CPU által megvalósított memória kezelés távol áll a teljes megoldástól – Minden folyamatnak saját címtere van – Különféle védelmi és megosztási elvárások – Memória foglalás, felszabadítás – Laphibák kezelése

• A memória menedzsment megvalósítása az OS feladata, ehhez a hardver, mint „végrehajtó” segít


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 • 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ésről 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. – Előzetes (prepaging) betöltés esetén nem csak a hivatkozott lapot, de az azt követő néhány lapot is betöltjük • 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.


Betöltési (fetch) politika • A betöltési politika kétféle lehet – Igény szerinti (demand) betöltésről 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. – Előzetes (prepaging) betöltés esetén nem csak a hivatkozott lapot, de az azt követő néhány lapot is betöltjük • 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 – Óra (Clock)


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 – Ó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


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-é.


Clock algoritmus •

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. – A 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. – 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.


Példák


Page Buffering • Problémák – 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


Page Buffering • FIFO algoritmus, de nem dobja el rögtön a lapot, hanem lista végére írja – Szabad lapok listája (nem változott) – 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) • 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: – 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.


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: – 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.


Rezidens lapok kezelése Lokális csere

Globális csere

Fix lapszám

•A folyamathoz rendelt lapok száma állandó •Lapcserénél az eldobandó lap a folyamat saját lapjai közül

• Nem lehetséges

Változó lapszám

•A folyamathoz rendelt lapok száma időről időre változhat •Lapcserénél az eldobandó lap a folyamat saját lapjai közül

• Lapok száma változhat • Lapcserénél az eldobandó lap bármelyik memórialap lehet, függetlenül attól, 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ű: – 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 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 elvétele a folyamattó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) – 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ő.


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) – 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ő.


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 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 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), a teljes folyamatot (minden lap) a másodlagos tárolóra másolnia.


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 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 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), a teljes folyamatot (minden lap) a másodlagos tárolóra másolnia.


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 – 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.


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.

•

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: – a mutatók forgási sebessége – a fáziseltolás a két mutató között.


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: – a mutatók forgási sebessége – a fáziseltolás a két mutató között


Memória menedzsment paraméterek lostrfree

Amennyiben a rendszerben a szabad lapok száma ezen érték alá csökken, a rendszer megkezdi lapok felszabadítását

desfree

A rendszerben található lapok elvárt értéke

minfree

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

slowscan

Másodpercenként átvizsgálandó lapok számának minimuma (scan rate)

fastscan

Másodpercenként átvizsgálandó lapok számának maximuma (scan rate)

Scan rate

Rendszer dinamikusan számolja, slowscan < sr < fastscan

A paraméterek kernel konfigurációjától, a fizikai memória mennyiségétől függenek. Sunday, March 21, 2010

Swapping • 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.


Operációs Rendszerek II. 5. előadás

Recommend Documents