Kernel

Joseph Pranevich frissítette A Linux 2.6 csodálatos világa című írását.A frissítés apropója a Linux 2.6.0-test9 kernel megjelenése volt. Valószínűleg már nem lesz frissítve a dokumentum a 2.6.0-ás stabil kernel megjelenéséig. A szerző egy változások listáját is mellékelt a dokumentumhoz.

Az írást megtalálod itt.

Igen, tudom, hogy volt már róla szó. A címben szereplő bejelentést a Open Source Development Labs tette ma.

Talán ez az első eset, hogy hogy test állapotban levő Linux kernel PR bejelentést kap.A PR bejelentésben már mint a 2.6-os Linux kernel karbantartóját említik Andrew Mortont. A bejelentésben az OSDL felkéri a nagyobb felhasználókat, hogy teszteljék az új -test9 kernelt. Szintén szó esik a megjelenés előtt álló 2.6-os kernel új tulajdonságairól is, úgymint: magas fokú skálázhatóság, gyorsabb szálkezelés (köszönhetően a Native Posix Thread Library for Linux-nak), javított, kibővített eszközmeghajtó réteg, beágyazott rendszerek jobb támogatása, sokkal jobb desktop tulajdonságok, stb.

A bejelentést megtalálod itt.

Linus nemrég kiadta a 2.6.0-ás kernel 9. teszt verzióját. Linus azt írta levelében, hogy sokkal jobb hét volt ez, mint az előző, bár a patch elég kicsi - számára azonban ezis túl nagy, és a 10. teszt release-zel szeretné ezt még tovább csökkenteni.A következő verzióba már tényleg csak kritikus fixeket fog fogadni. Tosatti (a jelenlegi 2.4-es kernelfa karbantartója) megkérdezte, hogy akkor most mi lesz a test10 után? Ugyanis Linus azt írta levelében, hogy utána át fogja passzolni Andrew Mortonnak (a 2.6 leendő karbantartójának az irányítást). Al Viro felvetette, hogy mi is számít Linusnak kritikus fixnek. Úgy tűnik egyre közeledünk az első 2.6-os kernelhez?

Linus levele itt.

A teljes forrás pedig itt.

Eli Billauer egy új véletlenszám-generátor modult (Random Number Generator - RNG) írt a Linux kernelhez. Állítása szerint az ``frandom'' egy gyorsabb verziója a jól ismert /dev/urandom-nak. Az frandom nem az urandom helyett készült, hanem azt kiegészítendő. Ha nagy mennyiségű pszeudorandom adatra van gyorsan szükség, akkor az frandom jobb választás lehet az urandom-mal szemben, mivel az frandom 10-50-szer gyorsabb az urandom-nál.Az frandom nem titkosító és biztonsági programokhoz készült. Sokkal inkább tudományos szimulációkhoz, merevlemez törléshez, stb. használható.

A modul felhasználható a 2.2-es, 2.4-es és 2.6-os kernelekhez. Az frandom az RC4 titkosítási algoritmuson alapul.

Az új RNG készítője szerint a kódnak helye lenne a hivatalos kernel forrásban is. Ezzel a legtöbb kernelfejlesztő nem értett egyet. Egyesek szerint ezt a feladatot meg lehet valósítani felhasználói térben futó programmmal, mások szerint pedig nem egy új véletlenszám-generátorra van szükség, hanem a meglevő /dev/urandom-ot kellene jobbá (gyorsabbá) tenni.

Egy nagyon hosszú thread alakult ki ezzel kapcsolatban a kernel listán, amelyet megtalálsz itt.

A Linux kernel többek közt úgy próbál meg takarékoskodni az energiával, hogy megállítja a processzort, ha annak nincs munkája. A processzor ``alvási'' állapota rapszodikus lehet, mert ha a processzor éppen pihen, a timer interrupt (időzítő megszakítás) akkor is ``felkelti'' minden 1/1000 - 1/100 másodperc időben. George Anzinger készített egy Variable Scheduling Timeouts (VST) patchet, amely megpróbálja megszűntetni ez a nemkívánatos működést. Ezt úgy teszi, hogy eltávolítja a timer interrupt-ot, ha annak nincs dolga.

A kernel timer interrupt (időzítő megszakítás) biztosítja a kernel számára, hogy követhető legyen az eltelt idő azáltal, hogy frissíti (növeli) a jiffie-k értékét (jiffie-nek nevezik a Linuxban az egy processzor órajelnyi (processor tick) időt. egy jiffie (i386) általában 1/100 másodperc, kivéve Alpha platformon, ahol 1/1024 másodperc), és ezen kívül egyéb a kernel háztartásbeli és process accounting funkciókért felelős. Amikor a timer interrupt feldolgozásra kerül, akkor a kernel periodikusan ellenőrzi a timer listát, hogy lássa ha valamelyik kernel timer lejárt (expired). Ha valamelyik timer expired állapotban van, akkor a kernel meghívja a hozzá tartozó funkciót. A kernel timer-ek az egyik olyan mechanizmusai a Linux kernelnek, amelyek arra használhatók, hogy a jövőben elvégzendő munkát ütemezzünk. Futó processzek hiányában az egyetlen dolog amit el kell végezni az timer interrupt-ban, a timer lista karbantartása. Ha nincsenek futó processzek, akkor a VST patch a következőt teszi: egy idle taskot idéz elő, amely ellenőrzi a timer listát, és megakadályozza a timer interrupt bekövetkeztét, ha a listán nincsenek olyan timerek, amelyek a következő timer tick-ben járnak le.

Amikor a rendszer idle állapotban van, és nincsenek futtatandó aktív taskok, de mondjuk egy hardveres megszakítás érkezik, akkor az megváltoztatja a helyzetet. Ebben az esetben a patch az alacsony szintű megszakítás-kezelő kódhoz fordul, hogy újra engedélyezze a timer interrupt-ot.

A patch előnye tehát az, hogy energiát takaríthatunk meg azzal, hogy a rendszer hosszabb időn keresztül tud pihenni, ha a idle állapotban van. Azzal, hogy eltávolítjuk a szükségtelen timer interrupt-okat, a processzor tovább maradhat ``alvó'' állapotban. Ennek a dolognak az akkumulátorral hajtott számítógépek tulajdonosai minden bizonnyal örülni fognak.

George Anzinger bejelentése itt.

Az egyik kernelfejlesztő próbálgatta a 2.6.0-test kernelt egy 16MB fizikai memóriával rendelkező gépen. A megfigyeléseit elpostázta az LKML-re. A fejlesztők megállapítása szerint van még mit alakítani a 2.6-os kernelen, hogy az megfelelően működjön egy ilyen low-end vason.

A mai világban a 16MB memóriával rendelkező gépek nem nevezhetőek éppen korszerűnek, de vannak emberek akik még szeretnék a régi gépeiket használni (nem beszélve a beágyazott rendszerekről, ahol a 16MB memória nem is olyan kevés). Az fejlesztő tesztjének egyik legszembetűnőbb eredménye az volt, hogy a rendszer memória egy jelentős részét az ``inode'' és a ``dentry'' (directory entry) cache foglalja el. Ezek a gyorsítótárak valójában a boot időben rendelkezésre álló memória 10%-át emésztik fel. Ha a fejlesztők megtalálnák a módját annak, hogy hogyan lehetne az ``inode'' és a ``dentry'' gyorsítótárak méretét csökkenteni, akkor azzal jelentősen megkönnyítenék a kis memóriával rendelkező gépek tulajdonosainak az életét.A hackerek arra a megállapításra jutottak, hogy a bűnös ebben az esetben a sysfs (a 2.6-os kerneltől kezdve a /proc virtuális filerendszert felváltani hivatott filerendszer). Minden egyes a sysfs-ben létrehozott bejegyzés egy ``inode'' és egy ``dentry'' bejegyzést hoz létre, amely benne marad a memóriában egészen a rendszer működéséig (reboot vagy kikapcsolás).

A probléma egyik megoldása az lehet, hogy teljesen megszabadulunk a sysfs-től. Andrew Morton készített egy patchet, amely egy ``nosysfs'' + ``root=NN:MM'' opcióval való bootolást tesz lehetővé számunkra. Ez a lehetőség főleg a beágyazott rendszerek készítőinek lehet hasznos. Mivel a sysfs egyre nagyobb szerepet kap az operációs rendszer működésében/működtetésében (fontos kommunikációt végez a felhasználói tér (user space) és a kernel tér (kernel space) között) lehetetlen kihagyni anélkül, hogy ne vezetne valamilyen hibás működéshez.

Egyelőre igazi megoldás nincs, a végső megoldást valószínűleg valamilyen ügyes filerendszer hack hozza majd meg.

A meglehetősen hosszú thread itt.

A 2.6-os stabil kernel VM (virtuális memória) alrendszerében be fog mutatkozni egy olyan funkció amelyet ``swappiness''-nek hívnak. A ``swappiness'' a kernel virtuális memória alrendszerének finomhangolására használható. A ``swappiness''-en keresztül megadhatjuk a kernelnek, hogy mennyire részesítse előnyben a ``pagecache''-t a ``mapped memory''-val szemben.



Ha a ``swappiness'' értéke 100-ra van állítva, akkor a kernel mindkét memória típust egyenlő mértékben kezeli. Ha az értéke 0, akkor a kernel sokkal inkább a ``pagecache''-t részesíti előnyben. Magyarul, ha a ``swappiness'' értéke magasabb, akkor a kernel többet lapoz (swap-pel), ha a ``swappiness'' értéke kisebb, akkor a kernel megpróbálja elkerülni a lapozást.A 2.6-os Linux kernelben a ``swappiness'' alapértelmezett értéke 60. A ``swappiness" a /proc-on keresztül állítható a /proc/sys/vm/swappiness attribútumon keresztül.

Az könnyen belátható, hogy különböző felhasználás esetén más és más ``swappines'' érték lenne a legmegfelelőbb. Ha nagyobb fileokat másolunk, vagy video-t tömörítünk, akkor a 0 érték lenne a legmegfelelőbb. Ha sok alkalmazással dolgozunk egy időben, akkor a magasabb érték lenne az üdvözítő. Arról nem is beszélve, hogy az optimális érték függ a gépben levő fizikai RAM méretétől is. Az is látszik, hogy egy átlagos Linux felhasználó nem fogja az

echo "x" > /proc/sys/vm/swappiness

módon ezt állítgatni. Akkor mi a megoldás?

Con Kolivas, az ausztrál kernelhacker készített egy patchet, amely a ``swappiness'' értékét automatikusan szabályozza. A patch a 60-as default értéket 0-ra módosítja (lehető legkevesebb lapozás, ami a desktop felhasználó szempontjából a legjobb), és csak akkor módosul a ``swappiness'' értéke, ha a vm lapozási kényszer alatt áll.

Con levele benne a 2.6.0-test8-hoz való patch itt.

Marcelo kiadta a 2.4.23-pre8-as Linux kernelt."Hi,

Itt a -pre8... Többek között egy egész nagy mennyiségű ACPI javítást, hálózatos változásokat, hálózati driver változásokat, néhány IDE javítást, SPARC beolvasztást, SH beolvasztást, NFS javítást, fontos VM typo (elgépelésből adódó hiba) javítást tartalmaz.

Kérem azokat az embereket, akik IDE-vel kapcsolatos crash-eket láttak az Alpha gépeken az előző kernelekkel, hogy próbálják me ezt.

Jó mulatást."

Letölthető patch-2.4.23-pre8.bz2

A változások teljes listája Marcelo levelében itt.

Lássuk mit dolgoztak a fejlesztők az elmúlt órákban.

Len Brown elérhetővé tette a legfrissebb ACPI javításokat (ACPI 2.4, ACPI 2.6) a Linux kernelhez.

Jeff Dike végzett az UML (User Mode Linux) (UML: User Mode Linux (1. rész - a kezdetek), UML: User Mode Linux (2. rész - a kapcsolat)) 2.6.0-test8 kernelhez készült portjával. Jeff levele itt.Stephen Hemminger frissítette a CPUset patchét a 2.6.0-test8 kernelhez. Bővebben itt.

Greg KH kiadta az udev 005-ös verzióját. Greg levele itt.