win95 swap a ramdrive-ban

VF vf at elte.hu
Tue Jul 15 16:21:02 CEST 2003


Thus spake Auth Gábor:

>  A címfordítás nem kernelszintû szokott lenni, hanem egy-két szintû TLB 
> táblákon át. Aminek fizikai címen van helye, a processzor MMU egysége ezt 
> használja, ezt pedig a kernel írja-olvassa. Nincs másolat. Az MMU egy 

Pontosabban a prociban belul van x bejegyzesnek hely.
Ha nem talalja meg, akkor a kernel berakja ezt a proci tablazataba az
OS sajat tablazatabol, melynek meretet nem korlatozza az MMU-cache,
csak a fizikai memoria. Ha ott az szerepel, hogy eppen nincs memoriaban,
akkor termeszetesen be kell hozni vinyorol.
Context valtaskor termeszetesen ki kell pucolni minden proci cache-t,
kulonben az uj program latna a reginek a memoriajat, illetve osszevesznenek
a kozos virtualis cimtartomanyon, stb...

>> Ehelyett az egyszer hasznalt lap bekerul a proci hardveres
>> MMU-tablajaba. Termeszetesen minden context
>> switchkor ki kell pucolni onnan, mint a sima data es instruction
>> cache-t is.
>  Egyre zavarosabb, amit írsz.

??? Ez igy mukodik. A prociban belul van MMU-cache, mely valahany lap
fizikai cimet tudja tarolni. Csak nem gondoltad, hogy minden egyes
olvasaskor az MMU vegignyalazza a kulso memoriaban talalhato tablazatot?
Mert az elso bekezdes alapjan nagyon ugy tunik hogy ebben (is) tevedsz!
Az kegyetlen lassu lenne, a belso tablabol forditas a modern procikon
mar egyaltalan nem igenyel plusz idot, ugyanannyi mint ha nem is lenne
bekapcsolva az MMU.

>> Ez attol fugg, mert az x86 szegmenses felepitese pl tudna, csak ezer
>> mas baja van.
>  Nem feltétlenül x86-ról van szó. Az összes 32 bites rendszerrõl.

Egy atlagos 32 bites rendszer 4G teruletet tud megcimezni.
Az x86 ennel joval tobbet, igaz ez nem linearis, hanem szegmentalt
cimtartomany. Ha az OS ugyes, semmi hardveres oka nincs egy 4G korlatnak.

>  De akkor sem képes megcímezni 2TBájt tárterületet fájlrendszerkezelõ 

Mint fent emlitettem, egyes 32 bites architekturakon ez nem problema.
Mas rendszereken igen.

>  CP/M esetén volt relokálás, DOS esetén .com fájloknál nem volt, .exe 
> fájloknál igen, VMS-t nem tudom, Windows esetén mindig van relokálás.

A CP/M fix 0100h vagy 1000h vagy valami ilyesmi cimre toltotte a programokat.
Amigan az elso programnal nincs relokalas, a masodiknal van.
Az elsoben nincs is reloc hunk.
A ketto kozott csak programozastechnikai kulonbseg van...

>  Nem másol... betölt... mindig, aztán ha nem kell, kiteszi swap-re. 
> Egyszerûen az adatmozgatás annyira megnõtt, hogy a program betöltése 
> elhanyagolható idõ lett az adatok betöltése/kiírása mellett. Például a 

Lehet hogy ma mar nem szamit, de egy idoben, amikor divat volt a
100 megas executable, ez rengeteget szamitott.

> programkódot swap-rõl olvas be, vagy eldobja és megkeresi a 
> programfájlból? Egyszerûen túl nagy rizikó az utóbbi.

A swap mindenkeppen riziko.

> Frank O'Yanco -=- Mobil +36-70/312-1856 +36-30/368-7792 -=- ICQ: 49179141

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"A lamerek egyik fo ismertetojele, hogy maniakusan felnek a virusoktol"



More information about the Elektro mailing list