Názory k článku
Zen Kernel: vytuněné linuxové jádro

„Linux-PHC umožňuje uživatelům podtaktovat procesor a snížit tak jeho příkon a teplotu.“ → „Linux-PHC umožňuje uživatelům snížit napětí na jádře procesoru a tím i jeho příkon a teplotu“.

Compsache : Abych se priznal, moc se mi tato uprava nezda. Je sice asi pravdou, ze pri dnesni velikosti pameti, by presunutim swapovanych stranek z jedne oblasti pameti do druhe, a naslednou komprimaci, mohlo dojit k jakemusi usetreni volnych segmentu pameti, ale za cenu rezie, kterou si vyzada komprimacni algoritmus. A tam plati, ze cim vykonejsi – tim pomalejsi. Je sice pravdou, ze pristup do pameti je radove rychlejsi, nez na disk, ale co z toho, kdyz mi tuto vyhodu sezere komprimace pri swapovani a decomprimace pri vypadku stranky? Mozna se mylim, ale spis bych se asi v tomto kontextu klonil k nazoru, ze pri dnesnich velikostech pameti ( > 2GB ) je swapovani lepsi vypnout…
LIRC, Zmena frekfrence procesoru : Nevim jak jinde, ale LIRC je normalne obsazen v Debianu, a k rizeni vykonu CPU tu mam balicky cpudyn, cpufreqd, cpufrequtitils, cpulimit, atd… Nevidim duvod proc to cpat rovnou do jadra a tim zbytecne zvetsovat jeho velikost a mnozstvi kodu, ktery bezi v kontextu jadra.
Jinak osobne si jadro (vanilla) kompiluji, dokonce – kdyz uz nevim co roupama – tak si jej zkousim spekovat, ale to jen velmi vyjmecne a opravdu v drobnostech… :-)

CompCache byl primarně vyvinut pro embedded zařízení nebo netbooky, které se distribují s malou RAM – např. s 128MB. Používám stařičký notebook (P3M 800Mhz s 192MB RAM) jako terminál a tady je znát každej MB, kterej se nemusí číst nebo zapisovat na disk. I na starším HW pak máte možnost dostat novější distro nebo pustit LiveCD. Je to slušně se rozvíjející se projekt:
http://code.google.com/p/compcache/

Přístup do paměti není řádově rychlejší, ale přesněji o 3 řády (dekadické) rychlejší (ms:ns). V případě rychlé komprimace, která si nedělá nárok na nejmenší velikost, to může být skvělý.

ms:ns to je 6 radu.. o 3 rady jsme jen na us :)

Ja som compcache pri ramke 512 MB používal a subjektívne to bolo cítiť. Ta komprimácia môže byť veľmi výrazna – napríklad ked sú v stránke samé nuly a pod… a nezabudni že porovnávaš rýchlosť (de)kompresie vs rýchlosť swapovania na/z HDD…

Dámy a páni, toto je presne ono. Už pár týždňov riešim I/O na disku spôsobené torrentami. Systém je tak len ťažko použiteľný.

Autorem projektu TuxOnIce je Nigel Cunningham, Pavel Machek je spíše v opozici, a vyvíjí konkurenční µswsusp (který ale potřebuje data v paměti zkopírovat a pak teprve je ukládá, takže odswapuje minimálně půlku paměti).

Už pár měsíců mám ve své verzi kernelu i pachte suse kernelu, spravované Janem Engelhardtem, kam spadá i CKO (colored kernel output). Nejzajímavější vlastností ale je zakázání locknutí CD mechaniky, což v patch formě je změna defaultní hodnoty jedné proměnné z 1 na 0 („one liner“).
.
Kdyby někdo měl zájem, nechť mrkne na git://dev.medo­zas.de/suse-kernel , adresář patches.addon/ , je tam i několik dalších fixů / vylepšení.
.
K článku – kromě zmíněných věcí – Linux-PHC není na podtaktování (což umí vanilla kernel už dlouho), ale na „undervoltage“ (to nevím, jak přeložit) procesoru. Většina procesorů je schopných pracovat při menší-než-defaultní voltáži a omezeném výdeji tepla bez ztráty výkonu. Nevýhodou je, že není žádná pevně stanovená hranice, za kterou bude CPU nestabilní, tu si každý musí najít sám. Myslel jsem, že Linux-PHC už dávno umřel, ale pokud ho někdo spravuje, jdu hned najít patche a aplikovat na svůj kernel.
.
V neposlední řadě mě zaráží – to v něčem tak komplexním, jako je Zen kernel, není ani unionfs? Osobně jen čekám, kdy se jeho dvojková verze dostane do vanilly, ale nezaznamenal jsem zatím nějaké výraznější pokusy, přestože patche jsou udržovány ve velmi aktuálním stavu.

„undervoltage“ – podpětí ;)

Podpětí je zcela správný a v elektrotechnice často používaný překlad/termín. Takže lze použít i bez smile. :)

rimmer :)

Pokryl jsem si celé fórum nápisy v hatmatilce!

Rozhodne bych si pral! Mohla by to byt prijemna cesta k tomu, jak postoupit ve znalostech s prijemnym benefitem rychlejsiho systemu. Pro mirne pokrocile uzivatele, do kterych se pocitam (uz nejaky ten cas (roky) pouzivam linux pro praci vyvojare, by to melo dle me velke benefity.

+1 ..

taky +1

pridavam sa

Také bych uvítal článek o kompilaci. Ještě jsem s tím neměl tu zkušenost a docela rád bych si vyzkoušel „Jak se to dělá“. Už kvůli tomu instaluji virtual machine :)

Dobry den, chybaju mi tu nejake nevyhody Zen kernelu (okrem nevyhody pre niektorych, ze je treba si to kompilovat). Keby to vsetko vyzeralo tak dobre, preco by ho nepouzivalo napr. aj Ubuntu, ktore uz teraz pouziva kopu vlastnych patchov?

Menší otestovanost ⇒ potenciálně nižší stabilita.

Support == 0, resp. optat se na forech a kdyz nekdo bude mit cas a naladu … ⇒ v komercnim prostredi nepouzitelne

Support bude urcite mensi nez u vanilla, ale nerekl bych, ze stejne spatny, jako u „nekterych“ komercnich os, se kterymi mam osobni zkusenosti. A jak znamo, support je treba, kdyz se neco vykydne. Takze pri zachovani standartni cesty test lab → produkcni system by nemelo byt vse relativne bezpecne.

I v Arch Linuxu je zen, byť jen v AURu. Našel jsem kernel26-zen. Zatím jsem nezkoušel.
http://aur.archlinux.org/packages.php?ID=30330
Ze článku to vyznělo tak, že zen je jen ve vyjmenovaných distribucích. Ale jinak dobrý článek. Možná by mohl být o něco podrobnější, ale aspoň na úvod to stačí.

Hmm, tak se nepovedlo:
include/linux/tra­cepoint.h: In function ‘tracepoint_syn­chronize_unre­gister’:
include/linux/tra­cepoint.h:80:2: error: implicit declaration of function ‘synchronize_sched’
make[1]: *** [arch/x86/ker­nel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

change the RCU implemantation in general setup->RCU implementation from classic RCU to tree RCU
http://forums.gentoo.org/viewtopic-p-6412279.html?sid=e30c0d3fac10511bf658b7b4a8ad98b1

Díky. Jen nevím, jak to skloubit s instalací přes yaourt. Asi bych to našel, ale…
Spíš ten link pošlu na diskuzi AURu.

Co máte za OS a IS, že se Vám to takto chová?

Díky za odpověď.

Madwifi to neřeší?

Skor toto by som pouzival:
http://aur.archlinux.org/packages.php?ID=13900

Zen-kernel (zen-sources) pouzivam uz od narozeni projektu a musim rict, ze posledni dobou umira. Vyvojari se venuji radeji rodinam (coz je jedine dobre), patchset je dostupny s velkym zpozdenim. Snad se situace casem zlepsi.
BFQ mozna vypada dobre, v praxi ma ale opacny ucinek – pri velkem I/O loadu se prestane hybat i kurzor mysi a Xka na nekolik sekund ztuhnou. Pozorovano na dvou nezavislych masinach s ruznym HW. Revert na CFQ problem castecne vyresi.
Naopak BFS je uzasna vec, zvysi interaktivitu pri zatezi do uplne jinych mezi, nez s klasickym CFS.
Bacha na integrovany lirc v 2.6.35-zen2 – oopsne pri natazeni modulu, je potreba zakompilovat externe, v upstreamu uz je to opravene.

Mne na velky I/O load pomaha vm.dirty_ratio=2 a vm.dirty_backgrou­nd_ratio=8. Je to na stroji, co ma 4 giga ram, takze povolim ulozit maximalne nejakych 80mega per proces. Defaultni hodnoty jsou daleko vyssi (20 a 10) a nez se takovych 800 mega zapise i na docela rychly disk, chvili to trva. Pro jine velikosti pameti se samozrejme hodi jine cisla. A je to platne na desktopu, kde chci slusnou interaktivitu.

Kdyby mi bylo dvacet a bydlel na koleji, tak bych si s tím možná hrál. Ale že mi je 28, tak si myslím, že je to spíš ztráta času, docela zajímavě ale vypadají ty alternativní plánovače.

Mi je 27 a kazdy novy release (jednou za mesic?) tim stravim cca 15 minut (a pouzitim genkernelu se tento cas jeste vice snizi). Pokud jsi jen uzivatel internetu a mailoveho klienta, asi ti to opravdu nic neprinese. Kazdy si v tom musi najit sve benefity.

Neumet cesky, sorry.

A vite ze ani dobra znalost ceskeho jazyka z Vas neudela o nic mensiho K*K*TA ?

Ďakujem za článok, bolo by dobré spomenúť aj ďalší alternatívny projekt spravovaný latinsko-americkou vetvou Free Software Foundation = linux-libre (http://www.fsfla.org/svnwiki/selibre/linux-libre/); taktiež udržiavajú vlastný set nástrojov resp. skriptov, tie však čistia a odstraňujú vybrané časti jadra, ktoré sú napojené (doslova „ťahajú zo sebou“) na ďalší proprietárny firmvér. Balíčky sú dostupné pre popredné GNU+Linux distribúcie odporúčané FSF, ale zahliadol som tam myslím aj napr. *.rpm pre Fedoru (pokiaľ sa niekomu nechce kompilovať).
PS: V súvislosti s lepšou odozvou linuxového desktopu ma napadli aj iné patche, ktoré však budú do klasického jadra včlenené najskôr od v. 2.6.37 (http://www.phoronix.com/scan.php?page=news_item&px=ODU0OQ alebo http://lkml.org/lkml/2010/8/26/327).

O Zenu jsem neměl ponětí, vypadá to moc dobře. :-)

Když je v jádře objevena chyba – jak rychle je vydána nová verze? Existují binární balíčky ZENu třeba do Ubuntu?
Distribuční jádro má opravy prakticky hned a stáhne se mi automaticky obratem.

Ja by som si to na Vistu dal, ale na http://www.zen-kernel.org/ nie je sekcia „screenshots“. :-(
(joke:-)

+1+1

Velmi zajímavé, o projektu jsem nevěděl.
Google mi pomohl najít debianovské balíčky.
http://liquorix.net/

ZEN kernelu nikdy nezapomenu onu legendární verzi 2.6.33, ve které se objevil Reiser4, přestože pro odpovídající mainstream kernel ještě žádný oficiální patch od Edwarda Shishkina neexistoval. Sice mi to přišlo podezřelé, ale řekl jsem si, že to prostě zkusím… Dobře mi tak!
To, co se stalo, byla naprostá katastrofa. Lidé od ZEN patchsetu zprasili Reiser4 tak, aby se prostě za každou cenu zkompiloval, bez ohledu na to, co ten kód ve skutečnosti dělá. Kdyby ten kernel aspoň včas odletěl, bylo by to fajn. Jenže to se nestalo – bohužel. Oddíl s Reiser4 byl totálně zničený během řádově pěti minut provozu. Sice pak fsck.reiser4 (spuštěný na jiném, nepoškozeném kernelu) dokázal tu spoušť dát celkem obstojně do pořádku, ale obrovská spousta souborů nenávratně zmizela. Objevily se i poškozené soubory.
Mohlo by mi to být jedno, protože příslušný počítač už v té době dávno nebyl můj hlavní stroj a obnovení dat ze záloh bylo poměrně snadné. Nicméně nakrklo mě to pořádně. Tohle by se nemělo stávat ani u tak experimentálních záležitostí jako je ZEN kernel. Od té doby mám jednoduchou zásadu: ZEN patchset prostě *NE*. Je lepší si patche, které obsahuje, stáhnout individuálně od původních autorů, nepoškozené a nepřiohnuté.
Mimochodem, co na to Phoronix? :-D To byl teprve nářez. Phoronix vzal ten nebezpečný ZEN patchset pro verzi 2.6.33 a na jeho základě udělal „benchmark“ Reiser4! Nevěříte? Tak pohleďte, tady je ten průšvih v celé své nahotě: http://www.phoronix.com/scan.php?page=article&item=reiser4_benchmarks&num=1 A pak klidně napsali, že Reiser4 není stabilní. Což zcela odporuje mým zkšenostem s Reiser4 jako s prvotřídním souborovým systémem, který je v celé řadě měřítek nejrychlejší a potíže se stabilitou na žádném z mých strojů nikdy neměl. (S výjimkou ZEN patchsetu…)

Lepsie vysvetlenie pojmu Vanilla je tu:
http://linux.about.com/cs/linux101/g/vanilla.htm

s/Compsache/Com­pcache/