[OSy] Second extended assignment - nejasnosti

[Vojtech Horky]

Dne 8.11.2017 v 09:26 Roman Firment napsal(a):
> Este k tomu poslednemu bodu:
> 
> * je postacujuce v implementacii pridelovania ASIDov pouzit indexovane 
> pole pripadne bitovu mapu?
Ano, bitmapa je celkem rozumné řešení.

Pokud by úloha nebyla hodnocena binárně, tak by určitě byly body navíc 
za bitmapu, kde je hledání volného bitu stylem next-fit, tj. 
neprohledávat vždy od úplného začátku.

- VH

> 
> Roman Firment
> 
> 2017-11-08 8:40 GMT+01:00 Vojtech Horky <horky at d3s.mff.cuni.cz 
> <mailto:horky at d3s.mff.cuni.cz>>:
> 
>     Dobrý den.
> 
>     Dne 7.11.2017 v 21:03 Roman Firment napsal(a):
> 
>         * kedy sa maju alokovat fyzicke ramce? V case ked vznika vma
>             alebo az v handleri vynimky TLB Refill Exception, pripadne
>         inde. Ak az
>             v handleri, tak co znamena ENOMEM (nedostatok fyzickej,
>         virtualnej pamati?) pri
>             volani vma_vmap?
> 
>     Už při volání vma_map().
> 
>     Pokud byste to volání odložil do refillu (něco jako Linux se
>     zapnutým overcommitem), mohla by dojít paměť (až později) a nebylo
>     by jak tuto chybu rozumně signalizovat zpět. Pokud byste tedy
>     nechtěl implementovat nějaký swapping a spol. :-)
> 
> 
> 
>         * moze nastat situacia, ze funkcia vma_map alebo vma_unmap bude
>         vykonavana
>             v inom mode nez kernelovskom?
> 
>     Ne, userland k ní přístup nemá.
> 
> 
>         * frame alokator v kaliste pouziva iba ramce zo spodnych 512mb.
>         Malloc pouziva
>             tento frame alokator. Vsetky struktury potom budu nutne
>         lezat v tomto segmente.
>             Nieje to problem?
> 
>     Pro účely cvičení to nevadí, jde o záměrné zjednodušení.
> 
> 
>     Frame alokátor má rozhraní připravené na podporu alokace rámců i z
>     dalších segmentů (VF_AT_* flagy). Takže pokud funkce pro namapování
>     paměti vidí, že k paměti bude nutné přistupovat skrz TLB, měla by
>     preferovat alokaci z oblasti nad 512M, protože těch spodních 0.5G je
>     "cennějších". Nicméně, námi dodaný frame alokátor podporuje pouze
>     Vámi zmiňovaných 512M, takže toto není nutné implementovat.
> 
>     Ještě pro úplnost - skrz TLB lze přistupovat i k identicky mapované
>     paměti, takže funkčnost TLB otestovat půjde.
> 
> 
>         * len pre istotu, ak nemusime implementovat ziadne dynamicke
>         priradzovanie asid-ov
>             a pocet vmm je omezeny poctom validnych asid-ov, tak nam
>         staci pouzivat jednoduche
>             inkrementovanie globalnej premennej ako je tomu v povodnej
>         implementacii kalista.
>             Alebo je ten pocet omezeny iba v jednom okamihu?
> 
>     Druhá možnost. Při vytvoření VAS se očekává, že rovnou dostane
>     přiřazený ASID, který je platný po celou dobu jeho existence.
>     Zrušením daného VASu se uvolňuje jeho ASID.
> 
>     Čili v jednom okamžiku může existovat max 255 VASů (resp. pokud
>     potřebujete nějaký ASID si vyčlenit pro speciální účely v rámci
>     kernelu, je ok podporovat "jen" 254).
> 
> 
>     Dává to takhle smysl?
> 
>     - VH
> 
>     _______________________________________________
>     OSy mailing list
>     OSy at d3s.mff.cuni.cz <mailto:OSy at d3s.mff.cuni.cz>
>     https://d3s.mff.cuni.cz/mailman/listinfo/osy
>     <https://d3s.mff.cuni.cz/mailman/listinfo/osy>
> 
> 
> 
> 
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy
>