Transcript SZGarchitekt_KGY10

Számítógéparchitektúrák
dr. Kovács György
DE AVK GAIT
A projekt az Európai Unió társfinanszírozásával,
az Európa terv keretében valósul meg.
Számítógéparchitektúrák
Társzervezés
A projekt az Európai Unió társfinanszírozásával,
az Európa terv keretében valósul meg.
2
Társzervezés




Mivel az aktuálisan nem futtatott programoknak nem kell a
főtárban lenniük, így azokat és a hozzájuk tartozó állományokat
tarthatjuk a háttértárolón is, és csak akkor töltjük majd be a
központi memóriába ha szükség van rá.
A főtár a számítástechnika eddigi története során mindig az egyik
legszűkebb erőforrás volt, mivel az egyre komplexebb
alkalmazások egyre nagyob méretű programokkal voltak
megoldhatók, és a kezelt állományok mérete is egyre nőtt.
A multiprogramozott, és a multitasking üzemmód elterjedését
követően vált jellemzővé, hogy a számítógépen „egyidejűleg”
több olyan nagy memória igényű programot kell futtatni, amelyek
együttesen nem férnek be a főtárba.
Az éppen nem használt programrészek és adatok háttértáron
való elhelyezését indokolja az a tény is, hogy az egységnyi
információtárolás költsége a háttértárakon töredéke a főtárhoz
viszonyítva.
HEFOP 3.3.1–P-2004-06-0071/1.0
3
Virtuális tárkezelés




Lényege az, hogy a processzor teljes címzési tartománya
tulajdonképpen egy háttértároló-területet jelent.
Ezen virtuális tárolónak csak egy része helyezkedik el az
operatív tárolóban, ahonnan a felhasználó futtat. A felhasználó
nem látja a szükséges háttértár–operatív tár átviteleket, ezért
úgy látja, mintha a processzor teljes címzési tartománya
rendelkezésére állna.
Egy tárkezelő egység (MMU = Memory Management Unit)
nyilvántartja, hogy az információ hol helyezkedik el, és a virtuális
címet az operatív tároló fizikai címévé alakítja át, ha a keresett
információ a tárolóban van.
Ha a keresett információ nincs az operatív tárolóban, akkor a
behozatalát kezdeményezi a háttértárolóról. Ezt az átvitelt az
operációs rendszer virtuális tárkezelő része hajtja végre.
HEFOP 3.3.1–P-2004-06-0071/1.0
4
A virtuális memória



Az operációs rendszer és a számítógép
hardvere által nyújtott szolgáltatás:
A futó program(ok) számára transzparens
módon biztosítja, hogy a program
végrehajtáskor az operatív memória fizikai
korlátai észrevétlenek legyenek.
Általában egy külső tárolóterület
(merevlemez) igénybevételével valósul meg
HEFOP 3.3.1–P-2004-06-0071/1.0
5
A virtuális memória
megvalósításának elve




Jelöljünk ki a háttértárolón a főtár memóriakapacitásánál jóval
nagyobb tárolóterületet úgy, hogy az egyidőben aktív
programfolyamatokhoz tartozó programok és adatállományok
ezen elférjenek.
Nevezzük ezt látszólagos, azaz virtuális tárterületnek.
A háttértárolón kijelölt virtuális tárolót osszuk fel blokkokra,
melynek méretét a lokalitás elvének figyelembevételével
határozzuk meg
A virtuális tárolóban 1 bájtot virtuális címekkel lehet megcímezni,
mely két alapvető részből áll: egyrészt megadjuk, hogy a keresett
bájt a virtuális tár hányadik blokkjában található, továbbá azt,
hogy az adott blokk kezdőcímétől számítva hányadik bájt (relatív
cím)
HEFOP 3.3.1–P-2004-06-0071/1.0
6
Virtuális tár és a cache
hasonlósága ill különbségei










A cache és a főtár viszonya
A különböző cache blokkok leggyakrabban azonos programokhoz
tartoznak.
A cache miss-t a hardver kezeli.
A cache nagysága (elvileg) független a processzor címterétől.
A cache kizárólagosan a tárkezelés céljaira szolgál, a programok nem
„látják”.
A főtár és a virtuális tár viszonya
Egy programfolyamat „egyidejűleg” más programfolyamatokkal együtt
fut, mindegyik folyamathoz önálló virtuális tárterület tartozik.
Ha egy blokk nincs a főtárban (blokkhiba) akkor ezt az operációs
rendszer kezeli.
A címtartományt meghatározza a virtuális tár nagysága.
A mágneslemezen a virtuális táron kívül más adatállományok is
megtalálhatók.
HEFOP 3.3.1–P-2004-06-0071/1.0
7
A virtuális tárkezelés
alapkérdései





Mekkora legyen egy blokk mérete? Viszonylag nagy tárterület célszerű
blokknak kijelölni, annak érdekében, hogy gyakran ne legyen szükség a
blokk cseréjére, mivel ehhez relatíve hosszú beolvasási idő szükséges.
Hova lehet egy blokkot beírni a főtárban? Tetszőleges helyre.
Ha be kell másolni egy blokkot a főtárba, akkor melyik főtár-blokkot
írhatjuk felül? Ezt az operációs rendszer dönti el algoritmussal,
leggyakoribb LRU (Least Recently Used) stratégia alkalmazása, mely a
processzor (programok) által legkevésbé használt blokk kiválasztását
eredményezi.
Ha megváltozik egy blokk a főtárban, mikor írjuk be a virtuális tárba? A
write back eljárás alkalmazása a célszerű, azaz csak blokkcserénél
aktualizáljuk a virtuális tárat, mert az aktualizálás jelentős időt igényel.
A virtuális tárkezelésre jellemző adat az alig 0,00001 – 0,001%-os
hibaarány (Miss-Rate), azaz ha a keresett adatot tartalmazó blokk nincs
benn a főtárban
HEFOP 3.3.1–P-2004-06-0071/1.0
8



A programok a virtuális tárat úgy látják,
mintha az a központi tár lenne.
A virtuális címzéssel elvileg megcímezhető
memóriaterületet virtuális címtartománynak
nevezzük.
Az elméletileg lehetséges virtuális címek
összessége, a gyakorlatban használható
virtuális címek mennyisége attól függ, hogy a
háttértárolón mekkora területet jelölünk ki
virtuális tárnak.
HEFOP 3.3.1–P-2004-06-0071/1.0
9
A virtuális cím leképezése
fizikai címmé

a processzornak a műveletvégrehajtás során a főtár
valódi, címeire van szüksége, tehát a virtuális
címeket át kell alakítani fizikai címekké. Ehhez két
dolog szükséges:


a blokkok háttértárolón található címét, a fizikai memóriába
bemásolt blokkok sorszámát, a fizikai kezdőcímét stb.
megfelelő táblázatokban nyilván kell tartani,
egy olyan program vagy hardver egység, mely a
memóriába bekerült blokkok adatait tartalmazó táblázatok
alapján elvégzi a virtuális cím fizikai címmé történő
átalakítását.
HEFOP 3.3.1–P-2004-06-0071/1.0
10
Az MMU


A virtuális címek fizikai címmé történő
leképezését az első virtuális tárkezelést
alkalmazó számítógépekben még az
operációs rendszer végezte.
Ma már kizárólagosan az jellemző, hogy ezt
a feladatot egy megfelelő címleképezési
áramköröket tartalmazó hardver egység, az
MMU (Memory Management Unit) végzi el.
HEFOP 3.3.1–P-2004-06-0071/1.0
11
Virtuális és fizikai címek
viszonya
HEFOP 3.3.1–P-2004-06-0071/1.0
12
Virtuális és fizikai cím
megfeleltetés
HEFOP 3.3.1–P-2004-06-0071/1.0
13
Az MMU működése
Az MMU a címleképezés mellett azt is figyeli, hogy a végrehajtandó
utasításban olyan virtuális cím van-e, mely olyan blokkra hivatkozik, mely
még nem került be a főtárba.
Amennyiben ilyet talál, akkor ez kivételt okoz, és az operációs rendszer
megszakításkezelő rutinja meghatározza azt a főtárba már bemásolt
blokkot, melyre várhatóan legkevésbé lesz szükség az következendőkben,
és ez kiírásra kerül a háttértáron lévő virtuális tárba, helyére pedig
bemásolásra kerül az a blokk, melynek adataira az aktuális utasítás
végrehajtásához szükség van.
HEFOP 3.3.1–P-2004-06-0071/1.0
14
Szegmentálás




Ha a virtuális tár olyan logikai blokkokból áll, melyeknek mérete
nem rögzített, akkor ezeket a blokkokat szegmenseknek, a
virtuális tárkezelésnek ezt a formáját pedig szegmentálásnak
nevezzük. A szegmensek átlapolódóan is megadhatók, azaz
ugyanaz az adat két különböző szegmensen belül is
megcímezhető.
Az átlapolódást a gyakorlatban legtöbbször úgy hasznosítják,
hogy több programfolyamat közösen használ szegmenseket.
A szegmentálásnál a logikai cím a szegmens sorszámát és a
megcímzett bájtnak a szegmenskezdettől való relatív címét
tartalmazza. A szegmens fizikai kezdőcímét a szegmenstáblázat
tartalmazza, ebből a szegmens sorszáma – melyet szelektornak
is neveznek – alapján lehet kikeresni a konkrét szegmens
főtárbeli kezdőcímét
fizikai cím = szegmens fizikai kezdőcíme + relatív cím
HEFOP 3.3.1–P-2004-06-0071/1.0
15
Szegmensek betöltési
stratégiák




első szabad helyre, azaz ebben az esetben a memória
kezdetétől kezdve megvizsgálásra kerül, hogy hol van az első
olyan szabad tárterület, melynek mérete lehetővé teszi a
szegmens betöltését,
következő szabad helyre, azaz utolsóként betöltött szegmenstől
kezdve vizsgáljuk az első olyan szabad helyet, ahova a
szegmens betölthető,
az ún. „legjobb helyre”, azaz az összes olyan szabad tárterület
közül, melyekben a betöltendő szegmens elfér, azt választjuk ki,
melynél a betöltést követően a legkevesebb szabad tárterület
marad,
az ún. „legrosszabb” helyre, amikor az a cél, hogy a betöltést
követően a szegmens mellett a lehető legtöbb tárterület
maradjon szabadon.
HEFOP 3.3.1–P-2004-06-0071/1.0
16
Lapozás


Ha a virtuális tár rögzített méretű nem
átlapolható blokkokból áll, akkor ezeket
lapoknak nevezzük, a virtuális tárkezelésnek
ezt a formáját pedig lapozásnak.
A főtár a lapmérettel megegyező nagyságú
részekre van felosztva, ezeket lapkereteknek
(frame) nevezik
HEFOP 3.3.1–P-2004-06-0071/1.0
17
Lapozás
HEFOP 3.3.1–P-2004-06-0071/1.0
18
Laptáblázatok
HEFOP 3.3.1–P-2004-06-0071/1.0
19
Címszámítás ha a lap nincs a
főtárban
HEFOP 3.3.1–P-2004-06-0071/1.0
20
Lapkiosztási elvek





Egyenletes elosztás: Legegyszerűbb eset, minden folyamat ugyanannyi
kerettel gazdálkodhat.
Arányos elosztás: a folyamatok virtuálismemória-igényeinek figyelembe
vételével döntünk, egy folyamat minél nagyobb virtuálismemória-területet
használ, annál több keretet kap.
Prioritásos elosztás: magasabb rendű folyamat extra előnyökkel
rendelkezik, tehát a hasonló igényű de alacsonyabb prioritású
folyamatoknál több lapot kap, és az azonos fontosságú folyamatokat
természetesen arányosan, vagy egyenletesen kezeli
Lokális elosztásról beszélünk: ha a rendelkezésre álló lapok száma egy
folyamat számára a futás során állandó,
Globális lapkiosztási stratégia: az operációs rendszer úgy rendelkezik,
hogy nem oszt ki minden lapot, csak a minimálisan szükségeseket, a
fennmaradó szabad lapokból a folyamatok dinamikus igényeit elégíti ki.
Előnye az, hogy rugalmasabb. Hátránya viszont, hogy vergődéshez
(trashing) vezethet. Ez akkor áll elő ha egy folyamat bármely okból olyan
kevés laphoz jut, hogy csaknem mindig laphibát okoz, fut ugyan, de futása
akár tízezerszer is lassabb lehet, mint normális esetben.
HEFOP 3.3.1–P-2004-06-0071/1.0
21
Lapcsere stratégiák


Az optimális stratégia (OPT): Azt a lapot
kell lecserélni, amelyre a legkésőbb lesz
szükség, hiszen így a bent maradó lapokkal a
lehető legtovább ki tudjuk elégíteni a lapok
iránti igényeket laphiba nélkül.
A lapcserénél előre kell tudni, hogy a
későbbiekben milyen sorrendben fogunk a
lapokra hivatkozni, így ez a gyakorlatban
megvalósíthatatlan
HEFOP 3.3.1–P-2004-06-0071/1.0
22
Előbb jött előbb megy




(First In First Out – FIFO): Azt a lapot kell lecserélni, amely
legrégebben van bent a memóriában.
Ez viszonylag egyszerűen megvalósítható, hiszen nem kell
hozzá más, mint egy egyszerű várakozási sor, amely olyan
hosszú, ahány kerete az adott folyamatnak van. Ezt az új FIFO
sort használjuk az adminisztrációhoz.
Minden frissen behozott lap sorszáma bekerül a FIFO sor
végére, ezáltal a sorban már bent lévő lapsorszámok eggyel
előre lének és a sor másik végén „kipotyog” a legrégebbi lap
sorszáma.
A FIFO elv az operációs rendszer legfontosabb lapjait állandóan
„kilapozza”, és ez sokszor nagyobb probléma, mint a kis
hatékonysága.
HEFOP 3.3.1–P-2004-06-0071/1.0
23
Legrégebben használt



(Last Recently Used – LRU): Azt a lapot kell lecserélni, amelyre
legrégebben hivatkozott a folyamat.
A rendszer hardver támogatást igényel, mert csak hardver
megoldás képes arra, hogy elviselhető időveszteséggel minden
egyes memóriahivatkozásnál módosítson egy, a lapok
felhasználási sorrendjét tartalmazó, FIFO jellegű listát, vagy a
laptábla erre szolgáló mezőjébe bejegyezze a hivatkozás
időpontját és laphibánál ezek közül megkeresse a legkisebb
értéket.
A módszer tehát viszonylag kevés laphibát eredményez, de
cserébe az adminisztrációs terhek szinte elviselhetetlenül
növekedtek.
HEFOP 3.3.1–P-2004-06-0071/1.0
24
Második esély





(Second Chance – SC): Az eljárás FIFO elven
alapul egy kis kiegészítéssel.
Minden laphoz – a laptáblába - elhelyezünk egy ún.
„hivatkozás” bitet, amelyet, ha a lapot használjuk,
automatikusan 1-esbe állítunk.
Laphiba esetén megkeressük azt a lapot, amely a
FIFO sor elején áll.
Ha ennek a lapnak a hivatkozás bitje 1, akkor
mégse őt válasszuk, hanem betesszük a FIFO
végébe, de 0-s hivatkozási bittel.
Ha a FIFO elejére olyan lap kerül, melynek
hivatkozási bitje 0, akkor lecseréljük.
HEFOP 3.3.1–P-2004-06-0071/1.0
25
Mostanában nem használt



(NUR) lapok cseréjét javasolja az LRU
módszer enyhített, könnyebben
megvalósítható változata.
A mostanában kifejezés azt takarja, hogy az
előző lapcsere óta használták vagy nem
használták a kérdéses lapot.
E módszernél általában a nullás jelzőbitű
lapokból véletlenszerűen választanak.
HEFOP 3.3.1–P-2004-06-0071/1.0
26