[so] CheckRamPoison

[Simona Maria]

Salutare
Razvanel, poate ti s-a luat sa explici aceleasi lucruri eu insa tot nu inteleg ce face testul 4 la acel check_ram_poison.
am urmarit thread-urile din anii trecuti legate de subiectul asta insa tot nu mi-e clar.



On Thu, 2008-05-08 at 12:45 +0300, Alexandru Mosoi wrote:
> pai... testeaza ca ramul e otravit :D. se otraveste swap-ul si apoi se
> forteaza aducerea unor pagini din swap in ram. acum paginile alea in
> ram trebuie si ele sa fie otravite, nu? (razvanel, corecteaza-ma daca
> gresesc).

Nu gresesti.

Pana aici am inteles.


Testul 4 "otraveste" swap-ul si apoi cauzeaza page fault-uri. Dupa page
fault-uri ar trebui ca cel putin o pagina din swap sa fie acum in RAM

de ce?

(este posibil sa fie _doar_ una daca in urma algoritmului de inlocuire
se lucreaza constant cu aceeasi pagina).

Daca nu se gaseste pagina "otravita" in RAM testul va pica.

Razvanel

Bun.
La mine paginile ajung din swap in ram doar daca au fost inainte swapate, indiferent daca mai este sau nu loc in ram. 
Mai exact, intai fac procedura de inlocuire a paginii daca este nevoie, daca nu iau primul loc liber si pe aceasta pozitie scriu in fisierul de ram paginile care au fost marcate - swapped. 
Pentru restu' de pagini se ia continutul din memoria virtuala. 

Inclusiv la ram_sync iau continutul din meoria virtuala.

Inca o observatie, paginile care au fost scrise in fisierul swap sunt scrise si in memoria virtuala, deci la ram_sync n-o sa-mi scape pagini anterior swapate. 

Iar paginile sunt swapate daca sunt dirty.(asta se intampla la primul page fault)
Imi scapa ceva?

Imi cer inca o data scuze si te rog daca poti sa mai clarifici o tzara.

Simona


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/so/attachments/20080511/3b0eb334/attachment.htm