( synapse | 2009. 04. 28., k – 11:24 )

"(Pl. MINIX-es webszerver uptime, nagy load melletti tesztek, ...)"

A minix mint rendszer egy a microkernel isteniteseert es Andrew bacsi e-penis meretenek a noveleseert letezik. A microkernel mint koncepcio nagyon elragado es elmeletben valoban nagyon biztonsagos, de a valosagban meg kell oldani azokat a problemakat amik monolitikus kernelek eseteben fel sem merulnek (pl.: MPI). Ez a "Szeparaljunk le mindent!" - torekves szerintem felesleges, ennyi erofeszitesbol mar ki lehet hozni azert biztonsagos, gyorsan mukodo kodot. Ha belegondolunk, hogy a processzek es a driverek ugyanugy user modban futnak ugy eleg megszamolni hogy hanyszor fog tortenni context switch es hanyszor lesz megjaratva az adat a processzek kozott. Andrew bacsi 10%-os teljesitmeny-visszaesest irt a minix2 kernel-mode drivers es a minix3 user-mode drivers kozott. Ez a szam szerintem meglepoen keves ahhoz kepest, ha elkezdunk dma-nelkul filet olvasni (nincs meg benne dma). Masik kerdes, hogy lehet-e egyaltalan benne dma. El tudom kepzelni, hogy a dma ring buffert egy shared memory segment-re irattatja az egyik process es erre mutato pointert es meretet ad at a system callnak. Igy a driver direkt lepakolhatja az adatot a process address space-ebe. Kerdes, hogy keresenkent modositani az SHM szegmens jogait, esetleg allokalni/deallokalni azt mennyi ideig tart (CS megintcsak). Egy fokkal nagyobb baj, ha mondjuk tcp stackrol beszelunk, mert ugye int->netdriver->ip->tcp->userspace esetben 4x kell atadni az adatot, ez minimum packetenkent 4 CS amennyiben a driverek kulon vannak implementalva. Nem is beszelve az adatmasolasi overhead-rol. Ha direkt tudnak irni egymas memoriateruletere, akkor erdekes race condition-ok, info leakek es egyeb humoros dolgok sulhetnek ki a dologbol, amit ugye nem lehet, mert a reliability az mindennel fontosabb.

Emiatt en azon a velemenyen vagyok, hogy azok a logikai egysegek, amiknek egyutt kell dolgozni, bizzanak egymasban. Enelkul a rendszert hasznalhatora nagyon nehez lesz megcsinalni. Andrew bacsi szerintem kicsit tullott a celon, maga a koncepcio kivalo (Xorg, egerdriver, bluteooth driver ne fagyaszthassa meg a gepem), de mondjuk ezt egy nagy I/O terhelesu hardvernel eljatszani nem lehet. Viszont ezek a komponensek vannak annyira primitivek, hogy jol meg legyenek tervezve/auditalva(/formalisan bizonyitva :)). Az, hogy ennek ertelme van embedded rendszereken, az hulyeseg: MMU nem sok embedded rendszerben van, amire az egesz minix erosen dependal, masreszt pedig embedded rendszerre szoktak irni sajat kodot, amit aztan szinten leauditalnak (ugyanis kicsi).

Emellett Andrew papa otletei elmeleti sikon jol hasznalhatoak es meg valoszinuleg fogjuk ertelmet latni a kutatasnak amit o vegez, de hogy ebbol hasznalhato rendszer nem lesz soha az biztos.

synapse

--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.

"Understanding the Linux Kernel" on page frame reclaiming