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