[OSy] Second extended assignment - nejasnosti

[AT]

Je to odpověď. Díky.

On 8 Nov 2017 20:03, "Vojtech Horky" <horky at d3s.mff.cuni.cz> wrote:

> 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
>>
>
>
>
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20171109/f0ac6e19/attachment.html>