[OSy] Rozsirene zadani 1.

[Martin Decky]

Hezky den,

> mel bych dotaz predevsim na cvicici, zda by bylo mozne usporadat
> vyjimecne cviceni z OSu zamerene na rozirene zadani 1 - predevsim na
> to, jak pracovat s vice procesory v msimu a jak vubec zacit s
> prechodem na viceprocesorove reseni (vim, ze manual zna odpoved asi na
> vse, ale teorie a praxe je casto dost odlisna).

Urcite bychom toto cviceni usporadat mohli. Navrhuji termin utery
25. 11. tradicne v 17:20 (bohuzel drive to asi nepujde, na utery 18. 11. 
i ctvrtek 20. 11. jiz mam jiny program). Pokud se tedy neobjevi nejake 
zasadni protesty proti tomuto terminu, tak s tim muzete pocitat.

> Jde mi predevsim o to, ze k zakladnimu reseni je k dispozici v Kalistu
> prakticky od vseho "neco" a da se s tim dobre pracovat. Bohuzel o
> viceprocesorovem reseni Kalisto nic netusi a pri implementaci bude
> treba sahat a menit Kalisto, jak tak predpokladam, i hluboko v
> netrivialnich neCeckovskych rutinach, ktere pouziva.

Nejake netrivialni zasahy budou opravdu potreba. Ale snazili jsme se na 
vsechna takova mista v Kalistu upozornit v komentarich (obcas i se 
zakladnim popisem myslenky, co udelat). Krome toho se musite rozhodnout, 
zda budete svuj system koncipovat jako zcela preemptivni (coz je stejne 
asi nejlepsi cesta pro rozumnou implementaci blokujicich syscallu apod.) 
nebo pouzijete nejake reseni typu "big kernel lock".

> Na cviceni by nas tym zajimalo predevsim - jak upravit bootovaci cast,
> aby si jednotlive startujici procesory neprepsali kontext/zasobnik.
> Dale jak modifikovat scheduler a jak pracovat s prerusenimi, ktera
> mohou chodit od vsech proceosru nezavisle.

Podle toho, co pisete, je videt, ze netapete uplne v mlze, ale spravne 
tusite, kde jsou ostre hrany, na ktere je potreba davat pozor. Takze 
pokud by nekomu stacil strucny navod na vyse polozene otazky:

1. Pri bootovani je potreba pomoci zarizeni dorder zjistit, na kterem 
procesoru zrovna bezite. Pokud bezite na procesoru 0, tak pokracujete
v inicializaci kernelu, memory managementu atd., zatimco na ostatnich 
procesorech budete cekat (klidne v aktivni smycce), az bude kernel
v takovem stavu, kdy muzete ostatni procesory "pustit dal".

Signal ostatnim procesorum (pri bootu a pripadne i jinde) predate opet 
pomoci zarizeni dorder, kterym lze posilat vyjimky mezi procesory (na 
platforme Intel se tomuto mechanismu obvykle rika "interprocessor 
interrupt"). Nebootovaci procesory uz vetsinou nic specialniho 
neinicializuji, ale pokracuji rovnou do (sve instance) planovace.

2. Kazdy procesor musi mit vzdy svuj privatni zasobnik a kontext (to se 
tyka i statickych bootovacich zasobniku a "safe place", ktere se pouziva 
pri obsluze preruseni). Pokusy z lonska, kdy se nektere skupiny snazily 
o temporalni (casove) a nikoliv prostorove oddeleni zasobniku, vedou 
vetsinou do pekel (nehlede na to, ze je to ve skutecnosti slozitejsi nez 
to delat tim nejintuitivnejsim zpusobem).

Pri obsluze preruseni muzete pouzivat registry k0 a k1 a pomoci nich 
zjistit ze zarizeni dorder (aniz byste museli sahat kamkoliv jinam do 
pameti), na kterem procesoru prave bezite, a podle toho zvolit vhodny 
zasobnik nebo "safe place".

3. Planovac ma typicky pro kazdy procesor svou nezavislou instanci, coz 
samozrejme vyzaduje vhodnym zpusobem zamykat struktury planovace (ready 
fronty atd.), pripadne mit pro kazdy procesor nezavislou frontu.

4. Velmi dulezita je spravna implementace synchornizacnich primitiv, aby 
skutecne fungovaly pri SMP behu spravne. Nemene dulezite je pochopitelne 
dusledne synchronizovani pristupu ke vsem sdilenym datovym strukturam.
V SMP konfiguraci mohou nastat nektere soubehy, ktere v UP systemu jsou 
z principu vylouceny -- vsechno je tedy potreba dukladne promyslet do 
vsech dusledku.


M.D.