win95 swap a ramdrive-ban

VF vf at elte.hu
Tue Jul 15 16:37:49 CEST 2003


Thus spake Auth Gábor:

>  Ismét mondom: nincs eldobható lap. Kilapozható lap van. Nem írható felül 
> semmivel.

Ez csak terminologia kerdese. (Remelem nem ezen akarsz vitatkozni,
mar tobb levellel ezelott detektaltam ezt a problemat)

>> A kulonbseg arnyalatnyi, elvileg vegul is nem kulonbozik,
>> tulajdonkeppen ugyanaz tortenik.
>  Hogy történne ugyanaz? Valamit még mindig nem értek... :)
>  Vegyük át még egyszer. Legyen
>  A - 1 program
>  B - Buffer
>  C - Cache
>  D - 2 program
>  F - üres
>  Legyen a memória tartalma
>  A-A-A-B A-B-B-C A-B-C-C C-D-D-A
>  Legyen a swap-en
>  A-A-A-D D-D-F-F F-F-F-F F-F-F-F
> 
>  Az 1 programnak szüksége van egy olyan lapra, ami kinn van swap-en. 
> Namost, ilyenkor annyi történik, hogy a kernel megkeresi a legrégebben 
> használt processz lapját, megnézi a cache területen ugyanezt, majd a 
> buffer esetén a legnagyobb prioritással kiírandó lapot. A kettõt 
> kicseréli. A memóriában lévõ lapok közül csak a ,,C'' jelüeket lehet 
> eldobni, a többit mindenképpen ki kell írni a swap-re, vagy terminálni a 
> processz futását.
>  Namost, erre a fenti két sorra mutasd meg, mit is gondolsz arra, hogy 
> eldob lapot, és esetlegesen cache-t tud nyerni a területén?

Nem eldobja, hanem kiirja. Ugyanugy mint a BSD eseten, csak eppen nem a
memoria elfogyasakor, uj alkalmazas inditasakor, hanem rendszeresen,
folyamatosan figyeli hogy melyik processnek mekkora working set-et adva
optimalis a rendszer mukodese, mekkora hanyada legyen a memorianak cache.
Ebben a szituacioban a bsd (allitolag) vegignezi a memoriaban az osszes
process osszes lapjat, megkeresi a legregebben hasznaltat, figyelembe
veve az egyes processekre beallitott parametereket, minimum es maximum
working set mereteket stb... Ez valoszinuleg NP teljes problema :)
VMS eseten a cache-bol barmely lap eldobhato (kiirhato) es helyette
betoltheto a szukseges, nincs overhead, nem hal meg a rendszer amig a
kswapd sziveskedik helyet talalni a memoriaban egy uj alkalmazas
inditasakor, tehat az atmeneti tulterheleseket sokkal jobban viseli.
Egyebkent a VMS errol hires. Halozatrol DOS es hasonlo jellegu tamadasokkal
szinte lehetetlen lefagyasztani, nem ugy mint egy unixot...
Az egyetemen annyit sikerult elerni, hogy egy szetszivatott gep eldobta
a halot teljesen, de nem fagyott le.

Meg egy kerdes: ha egy processnek limitalva van a working set maximalis
merete, akkor ezt hogy implementalod, hogy hatekony is legyen?
Mert bsd eseten vagy nincs limit, vagy a limit atlepesekor nem kap
tobb lapot, akkor sem ha lenne eleg memoria. VMS eseten ilyenkor is
mukodik a cache, memoriaban marad a lap, viszont ha barmely mas
processnek szuksege lenne ra, elveheti. Hatekony is, biztonsagos is.

>> Az tokmindegy. Nem kulonboztettem meg sehol a programkodot es a
>> programok adatteruletet.
>  Nem mindegy.

??? Akkor te kulonbozteted meg, de akkor meg nem kend ram.
En sehol sem kulonboztettem meg, es nem is emlexem hogy valaha lattam
volna ezen a szinten megkulonboztetest.

>  Hát, én pedig ezekkel foglalkozom...

VMS-sel? Hmm... Eddig nem ugy tunt!

>  Valami oka lehet... :))

Persze. Nincs uj gep. Nincs tobb VAX. Az Alpha is halodik...
A Compaq megvette a DEC-et, es evekkel ezelott bejelentettek hogy nem
lesz uj VMS, leallnak minden fejlesztessel.
Pedig egy csomo erdekes dolgot tudott, amit a mai oprendszerek azota sem.
Ez reszben a VAX proci specialis OS-tamogatasaval kapcsolatos.
Pl a fent emlitett memoria-modell, vagy a tobb image egy processben,
virtualis terminalok, acl, stb... Rengeteg erdekes dolog.

> 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/
"Az eg nem a csillagoknal kezdodik, hanem a fuszalak hegyenel. (J.M.)"



More information about the Elektro mailing list