kvp#61
"Minden procesznek van egy sajat lap tablazata (vannak kozos lapok). A hardver (MMU) kezeli ezt. Ha new/malloc (brk(), anonimous mmap()) foglalsz memoriat akkor rendszerint meg nem lesz a te processede a lap. Amikor eloszor fer hozza a process az eleteben, akkor kivetel keletkezik, es kernel neki adja azt a lapot, onantol kezdve kernel nem szol bele mit csinal vele (nincs buntetes)."
Ez a regi windows-ok mukodese volt. A midori eseteben epp az a jo, hogy egyetlen szemetgyujtos allocatator kezeli az egesz cimteret. Igy elofordulhat az is, hogy egy fizikai lapon tobb eltero folyamat adati vannak vegyesen. Maga a nyelv a biztonsagos, ezert becsuletesen soha nem fognak a folyamatok egymas adataihoz erni. Az uzenetkuldes (rendszerhivas) mindossze annyibol all, hogy az egyik folyamat atadja a kernelnek az adatterulet leirojat, amit az odaad a masiknak. Igy az adatokhoz hozza sem kellett erni, es megis sikerult a folyamatok kozotti kommunikacio.
"Task valtaskor rendszerint kiurul a TLB, kernel -> user mod valtaskor ill. vissza valtaskor nem,"
Process valtaskor. Szoftveres task valtaskor nem (pl. thread valtas). Mikrokernelek eseten a kernel jo resze is tobb masik process-ekben van, tehat neha egy rendszerhivas alatt tobb tucatszor is process-t kell valtani.
"usec alatt van egy mai processoron az ujboli kitoltese (nem kell teljesen kitolteni (Hardware vegzi), akar ns-ekrol is beszelhetnenk), kb. ms-onkent van task valtas-rol dontes (szervernel gyakran ritkabban (10ms)), (minden hoszabb I/O -ra valo varakozaskor is, ugye nincs sok ertelme azt a processt futatni ami adatok hinyaban all)."
A fenti pelda egy jatek eseten max. 100 task valtas/sec-t tesz lehetove. Igy egy jatek, ami a kernel-t hivja, ami a grafikuskartya driver-et hivja, ami a grafikat rajzolja, max. 25 hivast tudna megtenni masodpercenkent ha mikrokernelt hasznalnank. Mivel egyetlen kep kirajzolasahoz tobb mint 25 hivas kell, ezert az egesz rendszer hasznalhatatlan lenne ha a grafikus drivert kiszednenk a kernelbol es sajat process-t kapna. Ha viszont megnoveljuk a taszkvaltasok szamat, mondjuk 100-szorosara, akkor az elpazarolt ido is megno. A tlb toltesek jo resze pl. nem cache-bol jon, sot a mai x86-osok amugy is eleg lassan kezelik a process valtast. (a taszkvalto utasitasok eseten ez tobb ezer orajel/utasitas szokott lenni)
A midori nem az egyetlen jo megoldas. Ha a cpu kezelne rendesen az egy cimterbe telepitett tobb folyamatot, tehat tamogatna a fine grained protection-t, akkor is meg lehetne oldani a problemat (nagy asszociativ tabla kell csak hozza). Viszont az egyszeru es olcso, de gyors es nagy mennyisegu processzorok fele mozdul el a vilag. Arrol nem beszelve, hogy a singularity/midori eseten az os nagyobbik resze (meg a driver-ek is) teljesen platformfuggetlenek, tehat barmilyen cpu-n kepesek futni, fuggetlenul annak hardveres kepessegeitol. Vedett kod eseten akar egy lapkezeloegyseg (paging) nelkuli cpu is kepes virtualis memoriat hasznalni. (csak a szemetgyujto vezerlo fejlecebe kell tenni egy 'kilapozva xy helyre' jelzobitet) Igy egy objektum (programkod+adatok) tetszolegesen mozgathato a halozaton barmerre, mivel nincs adott hardverhez kotve. (kerulhet diszkre vagy egy tavoli gepre is) A rendszer vedelme addig tart, amig a memoriahaz kozvetlenul senki (egy programozo sem) sem ferhet hozza csak a kernel objektumkezeloje. Ha gep vedett modon kepes futtatni az alap kernelt (pl. beleegettek a bios-ba) es a par szaz soros kodban nincs biztonsagi res, akkor onnantol sokkal biztonsagosabba valik mint a jelenlegi windows-ok.