[so] [Tema5]Cum functioneaza swapper-ul? ( si testerul, ca tot suntem aici... )

[Florin]

Citat din enuntul temei:
"Daca nu mai sunt pagini fizice libere, biblioteca trebuie sa evacueze o pagina fizica in swap. Paginile din swap trebuie aduse in memoria fizica, atunci cand ele sunt accesate."

In tema nu se specifica insa nicaieri <<pe ce pozitie in swap>> se va evacua pagina fizica. Din pacate, eu am ales varianta in care sa mentin intr-o tabela, similara cu page table-ul, indicii paginilor din swap la care se gasesc pagini din memoria virtuala. 
Dupa ce m-am uitat atent pe codul test.c, mi-am dat seama ca alegerea facuta de mine a fost proasta, avand in vedere modul in care se face testarea. Si anume, citez din test.c, functia check_swap:

 for (i = 0; i < ppages; i++) {
                lseek (ram_fd, i * p_sz + offset, SEEK_SET);
                for (j = 0; j < checks; j++) {
                        read (ram_fd, &read_val, 4);
                        if (j == 0) {
                                page_id = read_val >> 16;
                                mapped_vpages[i] = page_id;  /// POS #1
                        }
[.....]
                 swap_count++;
                lseek (swap_fd, i * p_sz + offset, SEEK_SET);
                for (j = 0; j < checks; j++) {
                        read (swap_fd, &read_val, 4);
                        if (j == 0) {
                                page_id = read_val >> 16; /// POS#2
                        }
                        for (k = 0; k < ppages; k++)
                                if (page_id == mapped_vpages[k] && have_count != 0) /// POS#3
                                        check = 0;
                        check &= !(page_id ^ (read_val >> 16));

am incheiat citatu ! :D

Dupa cat am inteles eu din codul functiei check_swap, dupa cum se vede la POS#1 , se memoreaza in mapped_vpages niste id-uri de pagini virtuale, care se calculeaza pe baza valorilor stocate in RAM ( ugly hack, btw ). Apoi, in bucla de verificare a swap-ului, se calculeaza page_id-ul paginiii aflate in swap tot pe baza valorii citite din pagina din swap - vezi POS#2. Testul se asteapta, apoi, ca valoarile sa coincida - vezi POS#3 . Aceasta are loc daca, de exemplu, memoria SWAP ar fi indexata la fel ca si memoria virtuala, i.e. daca am pagina virtuala #tz , mapata pe pagina fizica #sh , si swapperul decide sa evacueze #sh din memoria RAM, pentru a face loc pentru alte pagini virtuale in RAM, atunci pagina #tz din memoria virtuala se asteapta de catre test sa fie mapata tot pe pozitia #tz in memoria swap!!! Am dreptate?

Daca da , atunci eu consider ca macar acest lucru trebuia specificat clar in enuntul temei, pt ca este un detaliu de implementare care poate impiedica trecerea anumitor teste. Nu consider ca este corect/...  ca, inainte sa ne apucam de o tema, noi sa trebuiasca mai intai sa citim testele si sa deducem de acolo cum ar trebui sa se comporte programul la rulare. 

Eu am ales ca pagina #tz sa fie mapata la swap_table[#tz], care poate fi diferint de #tz. Ma mir insa de ce nu imi pica testul...

Dar , in mod surprinzator, nu din aceasta cauza tema mea pica testele... Se pica la testul init2, subtestul swap_count. Acest test verifica daca swap_count ==have_count:

if (have_count != 0)
                test ("swap_count", swap_count == have_count);

Acuma, sa ne uitam cum se calculeaza swap_count:

[.............................]
    swap_count = 0;
  for (i = 0; i < vpages; i++) {

                lseek (swap_fd, i * p_sz + offset, SEEK_SET);
                read (swap_fd, &read_val, 4);
                if (read_val == SWAP_POISON)
                        continue;

                swap_count++;
[......................]
        }

Din ce am inteles eu, swap_count este egal cu vpages la finalul buclei, asta doar daca nu avem SWAP_POISON, si nu avem asa ceva in testul init2. Deci: in momentul apelului   test ("swap_count", swap_count == have_count); , swap_count == 3, si have_count == 1 ,  caci asa a fost apelata check_swap in run_test2. 

Intrebarea : de ce asa ??? Ce rol are have_count asta, ca din cod eu personal nu pot sa inteleg.

 
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/so/attachments/20070113/77f23b39/attachment.htm