[OSy] Second extended assignment - nejasnosti
Vojtech Horky
horky at d3s.mff.cuni.cz
Wed Nov 8 20:03:01 CET 2017
Dne 8.11.2017 v 18:44 AT napsal(a):
> 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.
Nedefinování určitých částí implementací může být (a je) součástí úlohy.
Např. vzhledem k API je korektní, pokud je ASID přiřazen až v okamžiku
vytvoření první oblasti. A podobně, při odmapování poslední oblasti může
být ASID odregistrován. Takže lze ASIDy recyklovat i bez existence
funkce vmm_destroy().
Je tedy na Vás jakou strategii zvolíte a jak se k daným omezením postavíte.
Je to odpověď na Vaši otázku nebo jsem to jenom více zamlžil?
- VH
>
> 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
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy
More information about the NSWI004
mailing list