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/
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.medozas.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.
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.
Kdybych si snad neco delal z internetove komunikace, tak bych byl ted smutny :) … Pro me by to rozhodne prinos melo, nejak vam nevim, proc se vlastne teda psali serialy na rootu na ruzne tema? proc se vydavaji knizky napr o Jave, kdyz je to vse v dokumentaci? Doporucuji vice radosti do zivota, mozna prestanete mit zapotrebi stirat lidi na forech a to bezduvodne.
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čí.
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
Mne sa kompilacia podarila. Zajtra rano skusim v praci nabootvat. Len mam mierne obavy z nvidia a wifi modulov – asi budem musiet prekompilovat voci ZEN jadru.
Uz mam aj prichystany I/O test – vytvaranie noveho HDD pre Virtualbox – toto mi zarucene vytazi system, tak ze nie som schopny ani vysunut Guake! konzolu.
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_background_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.
Ď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).
Ja by som si to na Vistu dal, ale na http://www.zen-kernel.org/ nie je sekcia „screenshots“. :-(
(joke:-)
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