Kernel

Linux kernel: 2.6.9-rc3-mm3

Címkék

Reggel óta elérhető a legújabb -mm patch a 2.6.9-rc3-as kernelhez. Csak egy lényegesebb változás van csak a szokásos javításokon és frissítéseken kívül. Ez pedig az ún. zaphod patch eltávolítása. Ez a Peter Williams féle Single Priority Array O(1) CPU Scheduler. Bővebben itt találsz róla leírást.

Letöltés: 2.6.9-rc3-mm3.bz2

Változások listája: itt

Filerendszer címkézés a SELinuxban

Címkék

``Filesystem Labeling in SELinux'' címmel jelent meg James Morris Red Hat kernel hacker írása a Linux Journal oldalain.A SELinux keretrendszernek szüksége van arra, hogy extra biztonsági információkat tároljon minden egyes fileról. A Linux ezt kiterjesztett attribútumok segítségével ezt lehetővé is teszi.

Morris a SELinux-nak, a Linux kernel hálózati alrendszerének és CryptoAPI-nak karbantartója, ezen kívül LSM fejlesztő és a Netfilter Core Team volt tagja.

A cikket megtalálod itt.

Cpufreq on-demand governor

Címkék

Az egyes kernelek kiadásakor sokszor kerülnek be olyan apró változtatások a kódba, amelyek felett hajlamosak vagyunk elsiklani. Csak akkor ötlenek szembe ezek a dolgok, ha tüzetesebben átvizsgáljuk a változások listáját, vagy a szokásos alapossággal konfiguráljuk kernelünket. Mivel kihagytam a 2.6.9-rc2-es kernelt, ezért csak a 2.6.9-rc3-ban vettem észre, hogy visszatért a 2.4-es kernel sorozatból általam már ismert, számomra hasznos funkió. Ez nem más, mint az on-demand (igény szerinti) CPU frekvencia állítási lehetőség.

Mivel életem nagy részét notebookon töltöm, nem mindegy, hogy azt hogyan teszem. Nem mindegy, hogy az akkumulátor mennyi idő alatt merül le, nem mindegy, hogy milyen időközönként kapcsol be a ventilátor (főleg éjjel, mikor a leghalkabb cooler is egy MIG-29-es hangjával süvít). Az akkumulátorral tudunk spórolni, ha a CPU-nk nem ``pörög'' teljes erővel akkor, ha nincs rá szükség. Szintén kevesebb lehet az egy órára jutó ventilátor-bekapcsolások száma, ha a CPU tud ``pihenni''. Természetesen már régóta lehet a CPU-k órajelét kézzel változtatni. De milyen jó volna, ha a rendszer automatikusan választaná ki az éppen aktuális munkának megfelelően, hogy milyen órajelen kell a processzornak üzemelnie, nem? Ez lehetséges, ezt hivatott elvégezni a cpufreq on-demand governor.

A 2.6-os kernelben több governor érhető el. Létezik ``performance'', ``powersave'', és mostantól ``ondemand'' is. A ``performance'' a rendszert teljesítményre hangolja, míg a ``powersave'' az energia megtakarításra. Az ``ondemand'' pedig igény szerint ``adagolja'' a CPU erőt. Azaz ha egy érdekes weboldalt olvasok, akkor nyilván nem kell annyi CPU, szépen leveszi az órajelet 300MHz környékére. Azonban ha bejön egy levél és elindul a SpamAssassin, vagy éppen a másik konzolon egy kernelt akarok fordítani, akkor szépen automatikusan felhúzza az órajelet a maximumra.

Nézzük egy példán keresztül:





A képen a sárga szekcióban az órajel folyamatosan csökken 2.4GHz-ről egészen 300MHz-ig. Azt, hogy milyen órajel tartományok közt szabályoz a governor, a sysfs-en keresztül tudjuk lekérdezni:

(2099MHz 57C) trey@alderaan:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

300000 600000 900000 1200000 1500000 1800000 2100000 2400000

Azt, hogy milyen elérhető governor-ok vannak a kernelünkben, az alábbi parancssal tudjuk lekérdezni:

(299MHz 58C) trey@alderaan:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

ondemand userspace

Azt, hogy melyik van az elérhető governor-ok közül éppen kiválasztva, így kérdezzük le:

(299MHz 58C) trey@alderaan:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

ondemand

A governor-ok közt váltani a következő paranccsal lehet:

(299MHz 59C) root@alderaan:/home/trey $ echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Nézzük mi történik, ha elkezdek az oldal elolvasása után tovább böngészni (zöld tartomány). A böngészéshez CPU erő kell, szépen felugrik az órajel 2.4GHz-re. Majd ahogy tovább olvasok, szépen elkezd ismét csökkenni, egészen 900MHz-ig (persze egész 300MHz-ig menne le). Ekkor eszembe jut, hogy kellene egy kernelt fordítani (piros tartomány). A másik konzolon indítok egy make-et, és látszik, hogy amíg az dolgozik, addig az órajel 2.4GHz-en marad. Persze a fordítás után majd szépen kezd visszaesni, egészen akár 300MHz-ig.

Az egészben a legjobb az, hogy semmiféle user space daemon nem kell ehhez, az egész kernel-térben van megoldva. Az eredmény: (várhatóan) hosszabb üzem, (várhatóan) kevesebb búgás.

A használatához az alábbi dolgok kellenek a kernelbe:

[ * ] Power Management support

CPU Frequency scaling --->

[ * ] CPU Frequency scaling

Default CPUFreq governor (userspace) --->

< * > 'ondemand' cpufreq policy governor

< * > CPU frequency table helpers

< * > ACPI Processor P-States driver

és a megfelelő CPUfreq driver, ami az én esetemben

< * > Intel Pentium 4 clock modulation

persze ez utóbbi processzortól függ, ehhez el kell olvasni a

Documentation/cpu-freq/*

írásokat.

Jó szórakozást!

Memória töredezettség- mentesítés

Címkék

Marcelo Tosatti tegnapi levelében egy olyan patchet postázott az LKML-re, amely a memória defragmentálását hivatott elvégezni.Marcelo munkája egy coalesce_memory() névre hallgató függvényt implementál, amely "zone" és "order" paramétereket vár.

A kód nincs még teljesen kész, SMP környezetben vannak még vele problémák, de egy processzoros rendszereken már szépen működik (pár percig :-) és könnyedén hoz létre nagy, fizikailag egybefüggő memória-területeket.

Marcelo levele itt.

Pánik villogó

Címkék

Andi Kleen munkájának köszönhetően elérhető a 2.6-os Linux kernelhez patch formában az a kód, ami megkönnyíti a rendszer-összeomlások detektálását.A 2.4-es kernelben már korábban is megtalálható volt az a funkció, amely rendszer pánik esetén villogtatni kezdte a billentyűzet ledeket. A látszólag haszontalan funkció hasznos lehet akkor, ha X futtatása alatt ``lefagy a rendszer''. Ha ilyenkor a billentyűzet ledek vadul villognak, akkor tudjuk, hogy a kernel pánikolt, és nem csak egy random lefagyásról van szó. Andi a korábbi kódot átnézte, kijavította, és portolta az új billentyűzet driverhez.

Andi megjegyezte, hogy még mielőtt valaki megkérdezi, nem tervezi a korábbi kernel pánik visszajelzése Morse kóddal munka portolását.

Bővebben itt.

DigSig

Címkék

A DigSig egy olyan Linux kernel modul, amelynek segítségével az adminisztrátor szabályozni tudja az Executable and Linkable Format (ELF) binárisok végrehajtását és a library betöltéseket.

Csak abban az esetben engedélyezi a binárisok futtatását, ha azokon érvényes RSA digitális aláírásokat talál. Az általunk futtathatónak ítélt binárisokat a Bsign programmal írhatjuk alá.A DigSig az Linux Security Module (LSM) hook-jaira épül. Fejlesztésének fő célja, hogy az adminisztrátornak segítsen megkülönböztetni a saját megbízható programjait a vírusoktól/ férgektől, egyéb gonoszságoktól.

A DigSig fejlesztéseit az Ericsson Research Canada végzi.

Nem rég jelent meg a DigSig 1.3.1-es verziója. A GPL-es forráskód letölthető innen. Bejelentés és rövid tutorial itt.

Moduláris IO ütemezők

Címkék

Jens Axboe keze nyomán a 2.6-os Linux kenrel IO ütemezői teljesen modulásriak lettek. Ennek köszönhetően a felhasználók futási időben képesek az egyes IO ütemezők közt váltogatni.

A patch alkalmazása után reboot-olás nélkül, ``on the fly'' választhatunk a Nick Piggin-féle anticipatory IO scheduler, a Jens Axboe-féle deadline vagy CFQ IO ütemezője, vagy éppen a noop IO ütemező között. Nem ez az első alkalom, hogy a fejlesztések arra irányuljanak, hogy röptében lehessen IO ütemezőt választani. Tavaly októberben Nick Piggin készített egy hasonló munkát.

``Miért van szükség az IO ütemezők futási időben való változtatására?'' - kérdezhetné bárki.Azért, mert a különböző IO eszközökhöz különböző IO ütemezők adják az optimális teljesítményt. A merevlemezekhez például optimálisan használható a deadline vagy az anticipatory ütemező, míg mondjuk egy memória-alapú eszköz (pl. USB mass storage) sokkal jobban működik a noop ütemezővel. A jövőben elképzelhető, hogy a kernel automatikusan fogja kiválasztani az éppen optimális IO ütemezőt.

Ezen előnyökön felül a modularitásnak köszönhetően ezután sokkal könnyebb lesz egy újabb IO schedulert illeszteni a kernelhez, mert ehhez a core kódot nem kell majd széttúrni.

A kezelőfelület a sysfs. A kernelbe mindenképpen bele kell fordítani egy IO ütemezőt fixen, a többi mehet modulba.

Az elérhető IO ütemezők lekérdezése:

bart:/sys/block/sda/queue # cat scheduler

anticipatory deadline [cfq]

A CFQ ütemező van kiválasztva. Modulba van forgatva a noop ütemező.

bart:/sys/block/sda/queue # modprobe noop-iosched

bart:/sys/block/sda/queue # cat scheduler

anticipatory deadline [cfq] noop

Látszik, hogy a modul betöltése után már elérhető a noop ütemező is. A CFQ-ról az anticipatory-ra való váltáshoz az alábbiakat kell tenni:

bart:/sys/block/sda/queue # echo anticipatory > scheduler

bart:/sys/block/sda/queue # cat scheduler

[anticipatory] deadline cfq noop

Bejelentés, patch Jens levelében.