<div dir="ltr">Este k tomu poslednemu bodu:<div><br></div><div>* je postacujuce v implementacii pridelovania ASIDov pouzit indexovane pole pripadne bitovu mapu?</div><div><br></div><div>Roman Firment</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-08 8:40 GMT+01:00 Vojtech Horky <span dir="ltr"><<a href="mailto:horky@d3s.mff.cuni.cz" target="_blank">horky@d3s.mff.cuni.cz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dobrý den.<br>
<br>
Dne 7.11.2017 v 21:03 Roman Firment napsal(a):<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* kedy sa maju alokovat fyzicke ramce? V case ked vznika vma<br>
   alebo az v handleri vynimky TLB Refill Exception, pripadne inde. Ak az<br>
   v handleri, tak co znamena ENOMEM (nedostatok fyzickej, virtualnej pamati?) pri<br>
   volani vma_vmap?<br>
</blockquote></span>
Už při volání vma_map().<br>
<br>
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. :-)<span class=""><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* moze nastat situacia, ze funkcia vma_map alebo vma_unmap bude vykonavana<br>
   v inom mode nez kernelovskom?<br>
</blockquote></span>
Ne, userland k ní přístup nemá.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* frame alokator v kaliste pouziva iba ramce zo spodnych 512mb. Malloc pouziva<br>
   tento frame alokator. Vsetky struktury potom budu nutne lezat v tomto segmente.<br>
   Nieje to problem?<br>
</blockquote></span>
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 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.<br>
<br>
JeÅ¡tě pro Ãºplnost - skrz TLB lze přistupovat i k identicky mapované paměti, takže funkčnost TLB otestovat půjde.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* len pre istotu, ak nemusime implementovat ziadne dynamicke priradzovanie asid-ov<br>
   a pocet vmm je omezeny poctom validnych asid-ov, tak nam staci pouzivat jednoduche<br>
   inkrementovanie globalnej premennej ako je tomu v povodnej implementacii kalista.<br>
   Alebo je ten pocet omezeny iba v jednom okamihu?<br>
</blockquote></span>
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.<br>
<br>
Č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).<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><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><br></div>