[OSy] Testy as2

[Ersin]

Dekuji za vycerpavajici odpoved.
Problem jsme jiz resili i s kolegou Babkou. Cely byl zalozeni na nasem nepochopeni zadani - ano, domnivali jsme se, ze vma_alloc slouzi jako zaklad procesoveho mallocu, a proto prideluje male bloky po bytech.
Jsem ale presvedcen, ze chyba nebyla pouze na nasi strane. Zadani sice rika, ze parametr size funkce vma_alloc musi byt zarovnan, nerika uz ale na kolik. Proto jsme automaticky predpokladali zarovnani na 4B.
Take testy nam vysvetleni neprinesly - protoze sice alokuji bloky velikosti nasobku stranky, neznamena to ale, ze by se nedalo alokovat mene.
Pokud se nad nasim pohledem zamyslite, zjistite, ze opravdu bylo mozne zadani pochopit nasim zpusobem a nikde jsme nenalezli nic, co by nam odporovalo:-)

Kolega Babka slibil, ze pro pristi rok zadani lehce poupravi, aby bylo na prvni pohled jasne, ze vma_alloc ma alokovat virtualni stranky pro procesy (vlakna), nikoliv male bloky.

Jeste jednou - dekuji za vysvetleni.

Stanislav Kozina

> Hezky den,
> 
> > Jedna se o alokaci ve virtualnim prostoru, adresa stranky je proto
> > prelozena na jinou stranku ve fyzickem prostoru. Problem je, ze
> > offset bloku v ramci stranky se samozrejme nepreklada - a tak test
> > vyzaduje alokaci bloku na zacatku stranky. Nase implementace na
> > zacatku stranky drzi hlavicky jednotlivych bloku s velikosti bloku
> > (ktere jsou nutne) - a tak odmitne alokovat od zacatku bloku.
> 
> Myslim, ze jste nepochopili zcela dobre, k cemu slouzi mapovani 
> virtualnich adres na fyzicke. Funkce vma_alloc() vytvori ve virtualnim 
> adresovem prostoru mapovani na fyzicke adresy, jinymi slovy priradi 
> jistym virtualnim strankam fyzicke ramce.
> 
> Jakekoliv bookeeping informace, ktere k vytvoreni a udrzovani takoveho 
> mapovani OS potrebuje, musi byt pochopitelne mimo tuto mapovanou pamet, 
> protoze proces pouzivajici dany virtualni adresovy prostor jej povazuje 
> cely za "svuj" a neceka v nem nejaka data, kterym by se musel vyhybat.
> 
> > Prijde mi zvlastni chtit alokovat od adresy 0 (ktera v Ccku vetsinou
> > znamena NULL).
> 
> Adresa 0 neni v zadnem ohledu specialni nebo jina nez jakakoliv nenulova 
> virtualni adresa. Nic nebrani tomu na tuto adresu ukladat data nebo z ni 
> dokonce vykonavat instrukce.
> 
> To, ze se adresa 0 (neboli NULL) v mnoha pripadech povazuje za neplatny 
> ukazatel nebo signalizuje chybovou hodnotu, je pouze konvence. Tato 
> konvence je bezpecna vzhledem k tomu, ze na zacatku virtualniho 
> adresoveho prostoru je vetsinou umisten entry point a inicializacni kod 
> uzivatelskeho procesu a tudiz nehrozi, ze by nekdo pracoval s NULL jako 
> s adresou nejake uzivatelske funkce nebo navratovou hodnotou funkce 
> malloc().
> 
> Nic by Vam ovsem nemelo branit namapovat nultou virtualni stranku na 
> nejaky fyzicky ramec pameti.
> 
> > Rad bych se proto zeptal - funkce vma_alloc() vyzaduje podle zadani
> > zarovnany parametr size. Mysli se tim zarovnany na 4B, nebo na
> > velikost stranky?
> 
> Pokud si uvedomite, po jakych nejmensich blocich muze funkce vma_alloc() 
> pamet mapovat, tak Vam bude odpoved na Vasi otazku jasna.
> 
> > Dale - proc vlastne funkce frame_alloc a vma_alloc
> > umoznuji donutit alokator k alokaci na dane adrese?
> 
> Predevsim: Funkce frame_alloc() je skutecne metoda alokatoru fyzickych 
> ramcu, ale funkce vma_alloc() je metoda spravce virtualnich adresovych 
> prostoru, ktery pouziva alokator fyzickych ramcu jen jako svuj backend 
> (prideluje mu volnou fyzickou pamet, kterou potom muze mapovat). Je 
> velmi dulezite uvedomit si rozdil mezi temito dvema API.
> 
> V pripade frame_alloc() se hodi specifikovat konkretni adresu ve fyzicke 
> pameti treba v tom pripade, kdy chceme oznacit jako pouzitou nejakou 
> cast fyzicke pameti, kde jsou pristupna hardwarova zarizeni. Je pravda, 
> ze se jedna spise o okrajovy pripad, typicky po frame alokatoru proste 
> chceme pridelit nejakou (celkem libovolnou) fyzickou pamet.
> 
> Naopak v pripade vma_alloc() je specifikovani konkretni virtualni adresy 
> typicka varianta. Kdyz vytvarite napriklad standardni layout virtualniho 
> adresoveho prostoru procesu, tak chcete presne zajistit, ze jeho kod a 
> staticka data budou zacinat rekneme na adrese 0, jeho heap na nejake 
> adrese tesne za koncem statickych dat a zasobnik bude naopak koncit na 
> adrese nekolik stranek pred koncem uzivatelskeho adresoveho prostoru.
> 
> > Prijde mi, ze
> > pokud nasim cilem je zajistit kazdemu procesu separovanou pamet, nad
> > kterou muze provozovat malloc(), neni tato funkce vubec potreba.
> 
> Lze si predstavit fungovani systemu, kdy kazdy adresovy prostor bude 
> sestaven zcela nahodne (resp. tak, jak urci nejaky algoritmus 
> pridelovani volnych virtualnich stranek) bez moznosti toho, abychom 
> layout presne nastavili. Je vsak trivialni domyslet, jak by byl system v 
> takovem pripade neflexibilni. Par prikladu:
> 
> * Kod by bylo potreba vzdy relokovat (nebo by musel byt napsat zasadne
>    position independent), protoze bychom nikdy nevedeli, od jake adresy
>    bude namapovan.
> 
> * Velikost oblasti virtualni pameti pro heap by nemohla rust podle
>    potreby.
> 
> * Zasobnik by nemohl pri preteceni rust podle potreby.
> 
> > Jedine rozumne reseni, ktere vidim, je zrusit hlavicky bloku. Jenze
> > pak by musela nekde existovat struktura s velikostmi bloku
> 
> Ano, to je skutecne prakticky jedine mozne reseni.
> 
> > a v te by bylo nutno vyhledavat - coz by bylo pomale.
> 
> Nerozumim Vasemu argumentu -- vyhledavani v te samostatne strukture je 
> prece v principu stejne rychle/pomale jako vyhledavani v te datove 
> strukture, kterou si ted ukladate na zacatky oblasti.
> 
> Kdyz se navic nad veci zamyslite poradne, tak zjistite, ze potrebne 
> informace si muzete napriklad ukladat ve stejnych strukturach, ktere 
> pouzivate k realizaci mapovani (at uz to jsou hierarchicke strankovaci 
> tabulky, hashovaci tabulky nebo cokoliv jineho) a tim se dostat i
> v nejobecnejsim pripade na konstantni casovou slozitost kritickych operaci.
> 
> 
> M.D.
> 
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
> 
> 
>