win95 swap a ramdrive-ban

[Auth Gábor]

Halihó!

2003. július 15. 14.33 dátummal VF ezt írta:
>>  Az OS MMU része azért is érdekes ebből a szemponból, mert a
> Igaz, de a proci MMU resze ugyanaz, csak ezt cacheli.
> Kulonben lehetne minden egyes memoriamuveletnel a kernellel fordittatni
> a cimet, kegyetlen lassu lenne.
  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 
egység, ami használja a TLB táblákat. Mind a processzorban, mint a 
kernelben.

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

>> Másrészt a címtartomány nagyon nem egyezik. Fájlrendszerben lazán
>> kezelünk jelenleg egy fájlszerveren ~2TBájt kapacitást hardveres
>> RAID5 tömbökből szoftveresen összefűzött (VVM modullal kezelt)
>> egybefüggő tárhelyet. Sem a processzor, sem az oprendszer MMU táblája
>> nem képes ekkora címtartományt kezelni 32 bites rendszeren. Így nem
>> is lenne képes visszatölteni a kilapozott programkódot a lemez
>> bármelyik részéről.
> 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.

> Egyebkent pedig csak processenkent kell szamolni a 4G
> limittel, a sok process memoria-hasznalata egyutt tullepheti a 4G-t
> siman. A VMS valamelyik verzioig 1G-t adott egy processnek, az ujabbak
> mar 4G-t.
  De akkor sem képes megcímezni 2TBájt tárterületet fájlrendszerkezelő 
alrendszer nélkül. Márpedig nem használhatja, mert fájlrendszerhiba 
esetén könnyen deadlock-ba kerülhet a kernel. Ezért a swap partíció és 
swap fájl egyedi fájlrendszerrel rendelkezik, nem lehet töredezett és nem 
lehet olyan fájlrendszeren, amihez a lapozás során más alrendszerenek is 
bele kell szólnia.

> Ha ilyen nincs benne, relokalasra nincs szukseg. Pl C64 basic, CP/M,
> DOS, VMS, talan a windows is?
  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.

>>  Elhiszem, hogy egy évtizedes VMS rendszer esetleg így csinálta, de
>> most a nagygépes rendszereknél az igények és a lehetőségek
>> túlhaladták ezt a módszert.
> Inkabb a lehetosegek :) Mert igeny lenne ra, sokkal hatekonyabb.
> Most adott esetben egy nagy file inditasa egy vinyorol vinyora torteno,
> logikailag felesleges masolassal kezdodik, ami agyrem.
  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 
memóriában 5M programkódhoz tartozik átlag 512M adat, nagygépes 
rendszerben SQL adatbáziskezelőnél. A lemezen ugyanez 5M / 20-30G arány 
lesz. 100-150-300M/s adatátvitel mellett kit érdekel, hogy 1M 
programkódot swap-ről olvas be, vagy eldobja és megkeresi a 
programfájlból? Egyszerűen túl nagy rizikó az utóbbi.
  10 éve nem így volt, de most ez a helyzet.
-- 
Frank O'Yanco -=- Mobil +36-70/312-1856 +36-30/368-7792 -=- ICQ: 49179141
FreeBSD (current stable branch) - Toshiba Satellite 1410
Key fingerprint E99D 1A55 0DF2 3AAC 2A15  FD55 0D71 B88D 35E5 C50D