[OSy] Second extended assignment - nejasnosti

[AT]

Mám doplňující otázku k předchozí otázce (ASID): Píšete
>  Zrušením daného VASu se uvolňuje jeho ASID.
Jak poznáme, že se má VAS zrušit? Úloha pro to nedefinuje žádné API, v
ukázkové implementaci se to vůbec neděje. Předpokládám, že naším
úkolem není přepisovat funkci thread_finish či nějakou jinou.

2017-11-08 9:51 GMT+01:00 Vojtech Horky <horky at d3s.mff.cuni.cz>:
> 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
>>
>
>
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy