Minixes tapasztalatok

 ( mrev | 2012. március 6., kedd - 14:23 )

Qemuban installáltam a Minix 3.2-t. Qemu-kvm-mel nem megy a bootolás (azonnal lefagy), kvm nélküli qemuval viszont működik. Az installált rendszer már kvm-mel is elindul, de néha mégis lefagy, ezért kvm nélkül használom. Amúgy, 64 bites bubuntu natty-n gyári qemuval nyomulok.

Legnagyobb előrelépés a NetBSD userland birtokbavétele: Replace the old and obsolete MINIX userland with NetBSD userland. Ugyanott: Switch to ELF. Ugyanott: Pkgsrc Upstreaming and Application Porting. Ugyanott: Asynchronous virtual filesystem (VFS) server.

Egy interjúban Tanenbaum ezt mondja: "Monolithic kernels are only used on systems where the reset button is considered a good solution to bad software". Értse ezt mindenki, ahogy akarja. Mindenesetre Tanenbaum sem egy mimóza.

Tudom, hogy semmi értelme, de engem az érdekel, hogy van-e olyan szinten a Minix, hogy portoljam rá a CCC-t. Elkezdtem ezért nézegetni, hogy s mint működik rajta a fordítás.

A doksi a pkgsrc-ből való fordításra a figlet csomagot hozza fel példaként, hát én is azzal próbálkoztam először. Az eredmény:

                 _
 _ __  _ __ ___ | |__   __ _   ___ _______ _ __ ___ _ __   ___ ___  ___ 
| '_ \| '__/ _ \| '_ \ / _` | / __|_  / _ \ '__/ _ \ '_ \ / __/ __|/ _ \
| |_) | | | (_) | |_) | (_| | \__ \/ /  __/ | |  __/ | | | (__\__ \  __/
| .__/|_|  \___/|_.__/ \__,_| |___/___\___|_|  \___|_| |_|\___|___/\___|
|_|                                                                     

Nem mértem, de a fordítás 30-60 percig tartott. Ok, kvm nélkül a qemu piszok lassú. A lassúság fő oka mégis a minix. Részletezem az élményt. Az idő nagy részében ilyesmi látszik:

Checking for long long...

Eltelik 10-20 másodperc - yes. Na végre. Így persze könnyen összegyűlik az 60 perc. Nézegetem mire használja a processzoridőt. A minix (tehát nem a natty, hanem az emulátorban futó minix) topjában ilyesmi látszik:

62 processes: 1 running, 61 sleeping
main memory: 2078372K total, 1799088K free, 1779928K contig free, 158128K cached
CPU states:   4.41% user,  42.97% system,  52.62% kernel,   0.00% idle
CPU time displayed (press 't' to cycle): user 

  PID USERNAME PRI NICE    SIZE STATE   TIME     CPU COMMAND
    7 root       5    0   1228K        74:32  20.14% vfs
   12 root       2    0   2032K        45:28   9.20% vm
   28 root       7    0    884K   RUN   1:54   5.58% procfs
   62 service    5    0  48752K        32:18   3.78% mfs
 1921 vermes     7    0    708K         0:00   2.96% top
   37 service    5    0   6012K        24:25   2.35% mfs
    5 root       4    0    212K         8:21   1.83% pm
 1373 root       7    0    648K         0:00   1.29% sh
   89 service    7    0    100K         0:00   0.15% random
   10 root       1    0    236K         0:26   0.05% tty
    6 root       4    0     32K         0:17   0.04% sched
  104 service    7    0    196K         0:04   0.01% rtl8139
    4 root       4    0    324K         0:00   0.00% rs
    8 root       3    0   3444K         0:03   0.00% memory

Ezek az adatok nagyjából tipikusak fordítás közben, bár a user CPU gyakrabban 2-3 mint 4%. Ez azt jelenti, hogy a tényleges feladatra a CPU idő 3%-a fordítódik. A top lista állandó éllovasai a vfs (virtual fs), vm (virtual memory manager), mfs (minix fs), ezek a system CPU-t fogyasztják (feltételezés). A kernel (az a bizonyos hatezer sor) tipikusan 50-60%-ot fogyaszt. Nagyon sokáig kell figyelni, hogy a topban egy-egy pillanatra felbukkanjon a gcc vagy a cc1. Összehasonítás képpen NetBSD-n hasonló fordítás közben a user CPU 20-50% között mozog. Következtetés: a NetBSD legalább 10-szer hatékonyabban használja a processzoridőt.

Hogy világosabb legyen. A gép fordít. Eközben a kernel (6000 sor) elfogyaszt 50% CPU-t, de a kernel maga biztosan nem fordít. A vfs (absztrakciós réteg a konkrét fájlrendszer felett) elfogyaszt 20%-ot, de a vfs maga biztosan nem fordít (sőt még csak konkrétan nem is ír/olvas, hanem requesteket közvetít). Akkor mi fordít? Hát a maradék 3% CPU egy része.

Jelenleg az mc-t fordítom pkgsrc-ból, most két napja megy (éjjel le volt állítva). Persze csak az az érdekes, hogy egyáltalán a végére tud-e jutni (már csak napok kérdése, jelenleg a glib-nél tart). Van idő tehát néhány megjegyzésre.

Bár logikusnak tűnik, hogy kis eszközbe kis os-t (minixet) tegyünk, szerintem a beágyazott rendszerek piacán nem létezik az a rés, amit Tanenbaum látni vél. Javítsatok ki, ha nem így van, de mintha mindenben Linux volna. Amellett a Minix nem is elég kicsi. Nincsen benne dinamikus linkelés (so), emiatt minden végrehajtható fájl nagy, gyorsan fogy a hely. A dinamikus linkelés hiánya funkcióvesztést is hoz, pl. látom, hogy valaki panaszkodik a minix levlistán, hogy a python-ban nincs bz2 modul. Nincs, mert a python nem tudja felszedni az so-ként implementált modulokat.

Az marha jó, hogy a saját vackok helyett átálltak a pkgsrc-re. Viszont tudatosítani kellene, hogy a pkgsrc (tízezer emberév munka) sokkal nagyobb érték, mint a minix. Ezért nincs értelme az olyan mondásoknak (szintén levlistában), hogy a pkgsrc-ben levő EDE még nincs portolva minix 3.2-re. Ehelyett úgy kellene hozzáállni a kérdéshez, hogy tegyük a minixet a pkgsrc alá, hozzuk olyan állapotra, hogy a pkgsrc-on a lehető legkevesebb (0) változtatásra legyen szükség. Szerintem ez kutatási témának is érdekesebb. Azt is el tudom képzelni, hogy elérhető volna a bináris kompatibilitás, vagyis a NetBSD binárisok futtatása minix felett. A FreeBSD is tud futtatni Linux binárisokat.

64 bit kell. Lassan 10 éve az ipar csak 64-bites processzort gyárt. Nehogy már azt a hatezert sort ne tudja úgy megírni, hogy annyi bitesen működjön, amilyen a processzor. Minél tovább halogatja, annál több baja lesz vele.

A minix fs marha jó flopidiszkre. Fejlődés viszont csak akkor várható, ha a minix felkerül a programozók fizikai pc-jére (nem emulátorba), ahhoz viszont kellene egy normális fájlrendszer, ami minimum a most kapható diszkeket kezeli, pl. egy SATA-t. Ehhez képest a doksi azt írja, hogy a minix kezel "egyes SATA diszkeket". Ami Tanenbaumot illeti, ő azt nyilatkozata, hogy Solaris és Windows XP van a gépein.

Végkövetkeztetés: Nem ellenszenves a Minix. Nem is állna messze attól, hogy használhatóvá váljon, ha a többi os nem fedné le teljesen a piacot. A mikrokerneles filozófiája miatt még így is érdekes. A NetBSD-vel való együttműködés jó ötlet. Ahhoz hasonló projekt kéne, mint a FreeBSD kerneles Debian.

Majd még ideírom, hogy sikerült-e lefordítani az mc-t.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én egy 486-oson próbáltam pár éve, azon piszok gyors volt. Én inkább arra tippelek, hogy a qemu aszinkron szolgálja ki a guestet, viszont a minix aktívan várakozik. Vagyis pl. amikor diskről olvasol, megkapja a vfs a kérést, az valahogy továbbítódik a qemunak, a qemu összelapátolja az adatot, de eközben hagyja, hogy a guest dolgozzon. Viszont a vfs nem hagyja, hogy eközben a rendszer mást csináljon, hanem vár a qemu válaszára.

Virtualboxban vagy vmwareben kellene kipróbálni, főleg az utóbbival sanszos, hogy be is bootol.

A VMware-ba eddig nem nagyon tudtam olyat tenni, ami nem bootolt be. Na jo, ez igy nem igaz, az OS/2 nem ment meg egy par eve.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A qemu helyett nem akarok mást, mert nem akarom feldúlni a bubuntut. Inkább majd összerakok egy valódi pc-t. Amúgy nekem elég sok rendszer fut qemuban: freebsd, netbsd, linux, w2k, ezekkel nincs baj, a kvm is jól működik.

Nem biztos, hogy igazad van a vfs-sel kapcsolatban. Nekem úgy tűnik logikusnak, hogy a vfs nem találkozik közvetlenül a qemuval, hiszen a vfs _virtuális_, azért ténylegesen nem ő olvas/ír, hanem csak közvetít a konkrét fájlrendszer felé, ami jelen esetben az mfs. Éppen ezért szúr szemet, hogy milyen rohadt sok időt fogyaszt. A wiki szerint a vfs nem volt még benne a korábbi minixekben.
--
ulysses.co.hu

Igen, picit pontatlanul fogalmaztam. Nyilván nem közvetlen a kapcsolat, erre akartam utalni: "megkapja a vfs a kérést, az valahogy továbbítódik a qemunak".

Sajos nincs időm ilyesmivel játszani, de azt azért megnéztem, hogy a telepítő szépen bebootol vmware playerben.

Felraktam egy valódi pc-re. Sokkal gyorsabb, mint kvm nélküli qemuban, de az arányok nem változtak: Tehát fordítás közben a topon hasonló számok vannak, mint a korábbi postomban. Más feladatokban viszont jobban muzsikál. Git repó klónozása közben, pl. kifejezetten fürge, nagy user CPU-val.
--
ulysses.co.hu

sub

Én is csináltam már egy tesztet a minix-el:
http://hup.hu/node/75327
Ez már régen volt, azóta lehet hogy fejlődött valamit. Ma már biztos Virtualbox-al próbálnám meg, az esik jobban kézre.

Talán ki lehetne hozni a dologból valami értelmes teljesítményt, ha több magos procira optimalizálással próbálkoznának. Egy magon váltogatni a process-ek között nem túl ígéretes a "fragmentált" IPC miatt.

Egy korábbi kísérletben egy korábbi Minix nekem is lefagyott a hálózatkezeléstől. Konkrétan ssh klienssel és sshfs-sel nyaggattam, és elég hamar megadta magát. Sem hálózaton, sem konzolon nem lehetett továbblökni, resetelni kellett.

A Minix 3.2.0 ebből a szempontból már teljesen jónak látszik. Egy furcsaság van: Ha ssh sessionben ctrl-c vel leállítok egy programot, akkor nemcsak a program áll le, hanem az ssh sessionból is kilép.

--
ulysses.co.hu

Egyelőre nem sikerült lefordítani az mc-t. A pkgsrc-ben kétféle mc van, 7-es és 6.4-es, egyik sem fordul. Az a baj, hogy az slang és az mc nincsenek összhangban. Megj: Az libslang2 is a pkgsrc-ből volt fordítva.

Próbáltam még a midnight commander weboldaláról az mc-4.6.1.tar.gz-t slang helyett ncurses-zel. Erre meg azt mondja a configure, hogy nem találja az ncurses könyvtárat, amit nem értek, mert természetesen installálva van.

Régen (10 éve) a midnight commander összes archív változata megtalálható volt forrásban. Most viszont a 4.6.1 a legrégebbi, amit találok. Nem tudja esetleg valaki, hogy hol vannak (ha vannak) a korábbiak?

--
ulysses.co.hu

Tapasztalatok (folytatás)

Az mc-t nem sikerült működésre bírni. Először az volt a baj, hogy olyan slang könyvtárbeli szimbólumokra akart hivatkozni, amik nem voltak definiálva a (pkgsrc-ből függőségként automatikusan leforduló) libslang2-ben. Miután továbblökdöstem, abba ütköztem bele, hogy a stat(), lstat() és társaik és az ezekhez tartozó konstansok hiányosan vannak csak meg a stat.h-ban. A minixes mc-t ezért feladtam, helyette linuxos mc-t használok sshfs-en keresztül linuxról.

Lefordítottam a CCC magját. Néhány dolog, ami hiányzott: ioctlsocket konstansok (FIONBIO), lchown.

Formálisan linkel so filéket, de aztán nem tudja azokat használni, úgyhogy be kellett állítani a fix static linkelést.

Ezután futnak a CCC programkészítő programok, lehet cli programokat fordítani, pl. hello worldot.

Nem találtam meg az X fejlesztő környezetet (Xlib.h és társai), ezért nem tudtam lefordítani a terminált. Helyette a linuxon futó terminált lehet használni, amihez port forwarding kell. A port forwarding (linuxról, -L és -R egyaránt) csakis akkor működik, ha a minixes sshd_config filébe ben van állítva GatewayPorts yes.

Ekkor már linuxon feljövő terminállal elindulnak olyan programok, mint a z, savex, mask. Kiderül azonban, hogy nem frissül rendesen a képernyő. A CCC terminál kétféle módban tud működni: sync és async (default). Szinkron módban a putrect azonnal küldi a változást a terminálra. Aszinkron módban putrect csak a screenbufferbe írja a változást, beállítja a dirty flaget, egy külön szál pedig rendszeres időközönként küldi az összegyűlt változásokat. Értelemszerűen az aszinkron mód többszálú. Ez a külön szálon történő frissítés akadozik, bizonyos billentyű leütésekre megtörténik, de nem megy automatikusan, ahogy kellene. (Egyáltalán, van a minixben preemptiv multithreading?) A szinkron mód viszont működik.

Szinkron módban már nem csak elindulnak, de futnak is a fullscreen karakteres programok. Kiderül azonban, hogy a szemétgyűjtés elakad. Jobban megnézve látszik, hogy nem akad el, csak nagyon lassú. Megj: A CCC-nek saját mark and sweep algoritmusú szemétgyűjtése van. Saját memóriagazdálkodást viszont nem végez, hanem közvetlenül a malloc-ot és free-t használja (vagyis a lehető legegyszerűbb). A sweep szakaszban hívott free() az, ami botrányosan lassú.

Összefoglalva:

1) A libc portolása még nem teljes.
2) Nincsenek dinamikus könyvtárak (so-k).
3) Mintha nem működne a multithreading.
4) A memóriakezelésen javítani kell.

--
ulysses.co.hu

A dlopen() hianya nem jelenti a dinamikus konyvtarak hianyat. Az utobbi gyak. azt jelenti, hogy a rendszer a fuggosegek alapjan meg tudja keresni a fuggvenyeket tartalmazo libeket, az elobbi viszont direkt fuggvenyhivast jelent egy konyvtarra. A ketto kozott apro terminologai elteres van...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem néztem, hogy konkrétan a dlopen-nel mi van, valószínűleg van valami dummy dlopen. Amit láttam az az, hogy a linker formálisan összrakja az so célállományt, viszont az így elkészült so nem használható semmire. A rendszerkönyvtárak között nincs egy so sem. A középtávú (vagy rövid?) to do listában Tanenbaum felsorolja a dinamikus linkelést.
--
ulysses.co.hu

Állítólag már dolgoznak rajta: Near-term projects

Azt írtam, hogy a mark and sweep szemétgyűjtés sweep szakasza (vagyis a memóriafelszabadítás) botrányosan lassú. Úgy néz ki, mintha lefagyna a program: Ami Linuxon kevesebb mint 1 sec, az Minixen fél óra. Megjegyzés: Elég nagy tesztprogramról van szó, ami milliónál több memóriaobjektumot tartalmaz.

Biztos, hogy a free lassú? Ideiglenesen beleírtam a CCC-be egy primitív memóriagazdálkodást: A program előre lefoglal egy nagyobb területet. Abban tömbszerűen elhelyez 8,16,32,... bájtos blokkokat, amiket felfűz egy-egy szabadlistába (minden méretnek saját, külön szabadlistája van). A szabadlistából ad memóriát a malloc, a free a felszabadított blokkot visszateszi egy szabadlistába. Egy ilyen modul 300 C++ sorba belefér, pár óra alatt elkészül.

Az alternatív memóriakezeléssel Minixen is normálisan (a Linuxhoz hasonló sebességgel) fut a tesztprogram.

Linuxon a modulból dinamikus könyvtárat (so-t) lehet linkelni, amit az LD_PRELOAD technikával előre be lehet tölteni, és így felül lehet definiálni az eredeti malloc/free/realloc függvényeket. Vagyis ugyanaz a bináris program tesztelhető az eredeti és alternatív memóriakezeléssel is. Az alternatív malloc/free 7:8 arányban gyorsabb, mint az eredeti.

Tanulság: A Linux (Windows, BSD-k) memóriakezelése jól meg van írva, hiszen alig lassabb, mint egy szélsőségesen sebességre optimalizált memóriakezelés. A Minix memóriakezelése viszont csak ideiglenesnek jó. Addig is legyen valami, amíg írnak egy rendeset.
--
ulysses.co.hu