<div dir="auto">Je to odpověď. Díky.</div><div class="gmail_extra"><br><div class="gmail_quote">On 8 Nov 2017 20:03, "Vojtech Horky" <<a href="mailto:horky@d3s.mff.cuni.cz">horky@d3s.mff.cuni.cz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 8.11.2017 v 18:44 AT napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mám doplňující otázku k předchozí otázce (ASID): Píšete<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  ZruÅ¡ením daného VASu se uvolňuje jeho ASID.<br>
</blockquote>
Jak poznáme, Å¾e se má VAS zruÅ¡it? Ãšloha pro to nedefinuje Å¾Ã¡dné API, v<br>
ukázkové implementaci se to vůbec neděje. Předpokládám, Å¾e naším<br>
úkolem není přepisovat funkci thread_finish Äi nějakou jinou.<br>
</blockquote>
Nedefinování určitých ÄÃ¡stí implementací může být (a je) součástí Ãºlohy.<br>
<br>
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().<br>
<br>
Je tedy na Vás jakou strategii zvolíte a jak se k daným omezením postavíte.<br>
<br>
Je to odpověď na VaÅ¡i otázku nebo jsem to jenom více zamlžil?<br>
<br>
- VH<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="tel:2017-11-08%209" value="+420201711089" target="_blank">2017-11-08 9</a>:51 GMT+01:00 Vojtech Horky <<a href="mailto:horky@d3s.mff.cuni.cz" target="_blank">horky@d3s.mff.cuni.cz</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dne 8.11.2017 v 09:26 Roman Firment napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Este k tomu poslednemu bodu:<br>
<br>
* je postacujuce v implementacii pridelovania ASIDov pouzit indexovane<br>
pole pripadne bitovu mapu?<br>
</blockquote>
Ano, bitmapa je celkem rozumné Å™eÅ¡ení.<br>
<br>
Pokud by Ãºloha nebyla hodnocena binárně, tak by určitě byly body navíc za<br>
bitmapu, kde je hledání volného bitu stylem next-fit, tj. neprohledávat vždy<br>
od Ãºplného začátku.<br>
<br>
- VH<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Roman Firment<br>
<br>
<a href="tel:2017-11-08%208" value="+420201711088" target="_blank">2017-11-08 8</a>:40 GMT+01:00 Vojtech Horky <<a href="mailto:horky@d3s.mff.cuni.cz" target="_blank">horky@d3s.mff.cuni.cz</a><br>
<mailto:<a href="mailto:horky@d3s.mff.cuni.cz" target="_blank">horky@d3s.mff.cuni.cz</a>><wbr>>:<br>
<br>
<br>
  Â  Â Dobrý den.<br>
<br>
  Â  Â Dne 7.11.2017 v 21:03 Roman Firment napsal(a):<br>
<br>
  Â  Â  Â  Â * kedy sa maju alokovat fyzicke ramce? V case ked vznika vma<br>
  Â  Â  Â  Â  Â  Â alebo az v handleri vynimky TLB Refill Exception, pripadne<br>
  Â  Â  Â  Â inde. Ak az<br>
  Â  Â  Â  Â  Â  Â v handleri, tak co znamena ENOMEM (nedostatok fyzickej,<br>
  Â  Â  Â  Â virtualnej pamati?) pri<br>
  Â  Â  Â  Â  Â  Â volani vma_vmap?<br>
<br>
  Â  Â Už při volání vma_map().<br>
<br>
  Â  Â Pokud byste to volání odložil do refillu (něco jako Linux se<br>
  Â  Â zapnutým overcommitem), mohla by dojít paměť (až později) a nebylo<br>
  Â  Â by jak tuto chybu rozumně signalizovat zpět. Pokud byste tedy<br>
  Â  Â nechtěl implementovat nějaký swapping a spol. :-)<br>
<br>
<br>
<br>
  Â  Â  Â  Â * moze nastat situacia, ze funkcia vma_map alebo vma_unmap bude<br>
  Â  Â  Â  Â vykonavana<br>
  Â  Â  Â  Â  Â  Â v inom mode nez kernelovskom?<br>
<br>
  Â  Â Ne, userland k ní přístup nemá.<br>
<br>
<br>
  Â  Â  Â  Â * frame alokator v kaliste pouziva iba ramce zo spodnych 512mb.<br>
  Â  Â  Â  Â Malloc pouziva<br>
  Â  Â  Â  Â  Â  Â tento frame alokator. Vsetky struktury potom budu nutne<br>
  Â  Â  Â  Â lezat v tomto segmente.<br>
  Â  Â  Â  Â  Â  Â Nieje to problem?<br>
<br>
  Â  Â Pro ÃºÄely cvičení to nevadí, jde o záměrné zjednoduÅ¡ení.<br>
<br>
<br>
  Â  Â Frame alokátor má rozhraní připravené na podporu alokace rámců i z<br>
  Â  Â dalších segmentů (VF_AT_* flagy). Takže pokud funkce pro namapování<br>
  Â  Â paměti vidí, Å¾e k paměti bude nutné přistupovat skrz TLB, měla by<br>
  Â  Â preferovat alokaci z oblasti nad 512M, protože těch spodních 0.5G je<br>
  Â  Â "cennějších". Nicméně, námi dodaný frame alokátor podporuje pouze<br>
  Â  Â Vámi zmiňovaných 512M, takže toto není nutné implementovat.<br>
<br>
  Â  Â JeÅ¡tě pro Ãºplnost - skrz TLB lze přistupovat i k identicky mapované<br>
  Â  Â paměti, takže funkčnost TLB otestovat půjde.<br>
<br>
<br>
  Â  Â  Â  Â * len pre istotu, ak nemusime implementovat ziadne dynamicke<br>
  Â  Â  Â  Â priradzovanie asid-ov<br>
  Â  Â  Â  Â  Â  Â a pocet vmm je omezeny poctom validnych asid-ov, tak nam<br>
  Â  Â  Â  Â staci pouzivat jednoduche<br>
  Â  Â  Â  Â  Â  Â inkrementovanie globalnej premennej ako je tomu v povodnej<br>
  Â  Â  Â  Â implementacii kalista.<br>
  Â  Â  Â  Â  Â  Â Alebo je ten pocet omezeny iba v jednom okamihu?<br>
<br>
  Â  Â Druhá možnost. Při vytvoření VAS se očekává, Å¾e rovnou dostane<br>
  Â  Â přiřazený ASID, který je platný po celou dobu jeho existence.<br>
  Â  Â ZruÅ¡ením daného VASu se uvolňuje jeho ASID.<br>
<br>
  Â  Â ÄŒili v jednom okamžiku může existovat max 255 VASů (resp. pokud<br>
  Â  Â potřebujete nějaký ASID si vyčlenit pro speciální ÃºÄely v rámci<br>
  Â  Â kernelu, je ok podporovat "jen" 254).<br>
<br>
<br>
  Â  Â Dává to takhle smysl?<br>
<br>
  Â  Â - VH<br>
<br>
  Â  Â _____________________________<wbr>__________________<br>
  Â  Â OSy mailing list<br>
  Â  Â <a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a> <mailto:<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a>><br>
  Â  Â <a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailm<wbr>an/listinfo/osy</a><br>
  Â  Â <<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mail<wbr>man/listinfo/osy</a>><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
OSy mailing list<br>
<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailma<wbr>n/listinfo/osy</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
OSy mailing list<br>
<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailma<wbr>n/listinfo/osy</a><br>
</blockquote>
______________________________<wbr>_________________<br>
OSy mailing list<br>
<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailma<wbr>n/listinfo/osy</a><br>
</blockquote>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
OSy mailing list<br>
<a href="mailto:OSy@d3s.mff.cuni.cz" target="_blank">OSy@d3s.mff.cuni.cz</a><br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/osy" rel="noreferrer" target="_blank">https://d3s.mff.cuni.cz/mailma<wbr>n/listinfo/osy</a><br>
</blockquote></div></div>