[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