win95 swap a ramdrive-ban

[Auth Gábor]

Halihó!

2003. július 14. 17.35 dátummal VF ezt írta:
>>  Ezt nem értem. Egy aktív, el nem dobható lap hogy a fenébe lehet
>> cache?
> Az a lap lesz cache, amely eldobhato, memoriahiany eseten is eldobodna.
  De miért lenne egy memóriabeli lap (amely nem cache lap) eldobható? Ha 
eldobható, akkor minek van még a memóriában?

>> Én ezt a szituációt úgy ismerem, hogy egy program fut, és olyan lapra
>> hivatkozik, amelyik éppen nincs a memóriában. Lapkivétel keletlezik,
>> és a kernel eldönti, hogy melyik memóriabeli lapot cserélje ki azzal,
>> amit be kell hozni a lemezről. Bufferbe nem fog férni, mert ahhoz is
>> lapot kell felszabadítani (kiírni), max aktív cache lapot tud
>> eldobni, ami nem szerencsés. A program futása felfüggesztődik, a
>> lemez-vezérlő queue-ba belekerül a két művelet (lapkiírás,
>> beolvasás); majd egy másik program kap processzort.
> A lenyeg ugyanez, csak kicsit ugyesebben megvalositva.
  Hááát...

> Ezzel a modszerrel az a baj, hogy egy process akkor is a memoriaban
> marad, ha nagyon reg nem volt hasznalva, az altala elfoglalt fizikai
> memoria nem hasznalhato cache-kent.
  Nem. Ha rágen nem fut, akkor a kernel VM tudja róla, hogy az általa 
használt lapok kilapozhatók, ha szükség van memóriára. De mivel futó 
program, csak éppen lockolva van valami I/O vagy hálózati művelet miatt, 
így nem dobható el a tartalma... nem lehet rá írni, csak mert éppen nem 
fut, mert később nincs honnan visszaolvasni a tartalmát.

> A windoz ilyenkor a cache kedveert kilovi az alkalmazasokat,
> olvashattuk hogy az szinten nem nyero.
  Dolog.

> A VMS folyamatosan monitorozza a processek memoria-hasznalatat, es a
> reg nem hasznalt lapokbol cache-t csinal.
  Ezt nem értem én. A process memória használatának elenyésző része 
szokott lenni a programkód. A nagy része adat, amit el kell menteni 
mindenképpen, vagyis nem lehet arra a területre lapozás nélkül más adatot 
rendelni. Ha viszont programkód, akkor sem szokás manapság a 
programfájlból visszatölteni az adatot, mert ezzel sokkal nagyobb rizikót 
és bizonytalanságot vállal fel a kernel, mintha kiírná azt a lemezre.

> Ha megis kell, azonnal rendelkezesre all, de kozben a cache-vezerlo
> felhasznalhatja a lapot ha kell neki. Igy a cache kedveert nem lovi ki a
> processeket, megis a leheto legnagyobb meretu cache-t hasznalja a
> diszk-muveletek gyorsitasara. Mondj ennel hatekonyabb modszert!
> Szerintem ma sincs. Ha a BSD nem igy mukodik, akkor nem nagy szam...
  Hát-hát... azért ennek nézz utána... :)

>>  De ehhez nagyobb cache és buffer veszteségek tartoznak. Egy egyszerű
>> számolásás feladatnál nem okoz gondot, de egy 100-150MB/s adatbázis
>> tranzakcióknál nem szerencsés a cache és a buffer rovására ilyeneket
>> csinálni...
> Eppen hogy noveli a cache hatekonysagat. Amikor egy lap kikerul a
> cache- be, semmilyen muvelet nem tortenik, az MMU-tablak atrendezesen
> kivul. Ez nem kerul semmibe, nem rontja a hatekonysagot.
  Nézd, ha több éve foglalkozol nagygépes rendszerek adminisztrálásával, 
és többtíz GBájt adatbázisok baszogatásával, akkor kezeld úgy a 
rendszereidet, ahogy gondolod. De tippem szerint a levelezésen kívül nem 
kerültél komoly kapcsolatba ekkora rendszerekkel... én tapasztalatból 
beszélek, és nem rég olvasott könyvek alapján...

>>  Akkor szar a BSD is... mégis, a leginkább és legstabilabban használt
>> operációs rendszer... :/
> Hat nem tudom szerintem ez csak jatekszer a VMS, VM/ESA es egyeb
> nagygepes rendszerekhez kepest... Latszik is hogy jobban ki van
> dolgozva.
  Adnál referenciát erre nézve? Nagyon kevés produktív VMS rendszer látok 
mostanában működni. A legnagyobb forgalmú webszerverek általában BSD 
alapon működnek.
-- 
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