Jaderné noviny - 12. 11. 2008

15. 12. 2008 | Jirka Bourek | Jaderné noviny | 3494×

Aktuální verze jádra: 2.6.28-rc4. Citáty týdne: Matthew Garret, Ingo Molnár, Andrew Morton. Sledování testerů a ohlašovatelů chyb. /dev/ksm: dynamické sdílení paměti. Smutný příběh ovladače em28xx.

Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.

Obsah

• Aktuální verze jádra: 2.6.28-rc4
• Citáty týdne: Matthew Garret, Ingo Molnár, Andrew Morton
• Sledování testerů a ohlašovatelů chyb
• /dev/ksm: dynamické sdílení paměti
• Smutný příběh ovladače em28xx

Aktuální verze jádra: 2.6.28-rc4

Současné vývojové jádro je 2.6.28-rc4 vydané 9. listopadu. Nic ohromně vzrušujícího. Různé malé opravy všude kolem. Je tu zpožděná aktualizace FAT, která zahrnuje nějaké přesouvání souborů, a dvě opravy pro některé dlouho známé problémy (ne regrese, ale ošklivé chyby) v předávání popisovačů souborů Unix domain. Toto vydání také obsahuje nový ovladač pro framebuffer Fujitsu MB862xx a zavedení nového interního API pro zacházení s maskami CPU. Všechny detaily najdete v kompletním changelogu.

V době psaní tohoto článku bylo od vydání 2.6.28-rc4 do gitového repozitáře hlavní řady začleněno těsně přes 200 oprav.

Současné stabilní jádro 2.6 je 2.6.27.5 vydané 7. listopadu. Obsahuje dlouhý seznam oprav doprovázený výzvou k aktualizaci silnější než obvykle. Aktualizace 2.6.27.6 je v procesu revidování; pravděpodobně bude vydána 14. listopadu.

Stabilní aktualizace jader 2.6.25.20 a 2.6.26.8 vyšly 10. listopadu. Obě obsahují dlouhý seznam oprav a obě by měly být poslední v daných sériích. Uživatelé, kteří na těchto aktualizací závisí, by měli zvážit přechod na 2.6.27 v blízké budoucnosti.

Citáty týdne: Matthew Garret, Ingo Molnár, Andrew Morton

Google měl být zajímavý případ velké společnosti, která najme lidi jak ze světa embedded zařízení, tak z existující linuxové komunity a vyrobí embedded zařízení, které má konkurovat tomu nejlepšímu z ostatních platforem. Hodně jsem doufal, že tato kombinace vlivů v linuxové komunitě jako celku zajistí, že lidé budou mít lepší povědomí o tom, jaká jsou omezení a potřeby pro vysoce kvalitní správu napájení v embedded světě, místo toho, abychom skončili s další hromadou kódu od výrobce, který sedí na FTP serveru někde na Tchaj-wanu a implementuje správu napájení pomocí [passing tokenised dead mice through a wormhole].

Do určité míry se mé naděje vyplnily. Dostali jsme git server v Kalifornii.

-- Matthew Garret

Měli bychom přestat používat CPP, což je zastaralá technologie z šedesátých let. Měli bychom se držet nové vlny sedmdesátých let a používat ten nablýskaný nový jazyk "C", který se na nás řítí s vlastnostmi jako typová kontrola a podobnými.

-- Ingo Molnár

Jestliže čtyři (zatím) hlavy vybuchly nad jedním kouskem kódu, možná to není vina těch hlav.

-- Andrew Morton

Sledování testerů a ohlašovatelů chyb

Opakujícím se tématem kernel summitů je vhodné uznání pro uživatele, kteří hlásí chyby a testují opravy. Tito lidé vývojovému procesu významně pomáhají, ale jsou mnohem méně viditelní než vývojáři, kteří tyto chyby vytvářejí. Protože bychom rádi měli více testerů a ohlašovatelů, má smysl je odměňovat jakkoliv to jde. Jednou z nejsilnějších měn, které máme, je uznání za práci, kterou udělali. Je tedy pochopitelné, že vyslovit uznání lidem, kteří napomáhají vývojovému procesu, je v zájmu všech zúčastněných.

Jedním mechanismem vyvinutým pro tento účel je sada značek aplikovaných na patche předtím, než jsou začleněny do hlavní řady. Když patch opraví chybu, uživatel (uživatelé), kteří ji nahlásili, by měli být zmínění přidáním značky Reported-by: (nahlásil). Podobně jsou testeři zmínění ve značce Tested-by: (otestoval). Jak se stává, někteří vývojáři si vypěstovali zvyk šetřit vzácné znaky nového řádku a používat Reported-and-tested-by: (nahlásil a otestoval) v případě, že uživatel patří do obou skupin.

Ze jména zmíněného v záznamu v changelogu v repozitáři zdrojových kódů jádra může mít člověk příjemný pocit, ale zviditelnění, které z této události vzejde, je relativně malé. Autor tohoto článku se tedy rozhodl hackovat svou utilitu pro data mining, aby tyto značky sledovala. Bez dalších okolků, tady jsou nejčastější ohlašovatelé problémů a testeři vývojového cyklu 2.6.27:

Nejvíce ocenění testeři

Značky Reported-by Adrian Bunk 43 21,0 % Robert P. J. Day 12 5,9 % Eric Sesterhenn 5 2,4 % Andrew Morton 4 2,0 % Alexey Dobriyan 4 2,0 % Denys Fedoryshchenko 4 2,0 % Yinghai Lu 3 1,5 % David S. Miller 3 1,5 % Vegard Nossum 3 1,5 % Stephen Rothwell 3 1,5 % Juha Leppanen 3 1,5 % Russell King 2 1,0 % Andi Kleen 2 1,0 % Ingo Molnár 2 1,0 % Benjamin Herrenschmidt 2 1,0 % Daniel J Blueman 2 1,0 % Daniel Exner 2 1,0 % Manuel Lauss 2 1,0 % Atsushi Nemoto 2 1,0 % Mikael Pettersson 2 1,0 %

Značky Tested-by: Ingo Molnár 7 4,6 % Andrew Savchenko 6 3,9 % Rene Herman 4 2,6 % Mariusz Kozlowski 3 2,0 % Alexey Dobriyan 3 2,0 % Tino Keitel 3 2,0 % Robert Jarzmik 3 2,0 % KOSAKI Motohiro 2 1,3 % Benjamin Herrenschmidt 2 1,3 % Larry Finger 2 1,3 % Kenji Kaneshige 2 1,3 % Jack Howarth 2 1,3 % Gerald Schaefer 2 1,3 % Dennis Jansen 2 1,3 % Daniel J Blueman 2 1,3 % Daniel Exner 2 1,3 % Steven Noonan 2 1,3 % Rus 2 1,3 % Lawrence Greenfield 2 1,3 % Mark Langsdorf 2 1,3 %

Celkem bylo během vývojového cyklu 2.6.27 zadáno 205 značek Reported-by: a 153 Tested-by:. To je pravděpodobně pro novou značku rozumný začátek, ale je jasné, že mnoho ohlašovatelů problémů tímto způsobem ještě oceněno nebylo. Autor článku byl zvědavý, kdo si našel čas, aby vyslovil těmto lidem uznání; i ti si nějaké uznání zaslouží. Další trocha hackování skriptu vydala tyto tabulky:

Vývojáři, kteří vyjadřovali uznání v 2.6.27

Značky Reported-by Adrian Bunk 44 21,5 % Linus Torvalds 12 5,9 % Ingo Molnár 8 3,9 % Andrew Morton 7 3,4 % Peter Zijlstra 7 3,4 % Bartlomiej Zolnierkiewicz 6 2,9 % Yinghai Lu 5 2,4 % Jarek Poplawski 5 2,4 % Jiří Kosina 5 2,4 % Hugh Dickins 4 2,0 % FUJITA Tomonori 4 2,0 % Paul Mundt 4 2,0 % Vegard Nossum 3 1,5 % Russell King 3 1,5 % Jeremy Fitzhardinge 3 1,5 % Roland McGrath 3 1,5 % Haavard Skinnemoen 3 1,5 % Dmitry Torokhov 3 1,5 % David Woodhouse 3 1,5 % Oleg Nesterov 3 1,5 %

Značky Tested-by: Pekka Enberg 7 4,6 % Linus Torvalds 7 4,6 % Takashi Iwai 5 3,3 % Bartlomiej Zolnierkiewicz 5 3,3 % Peter Zijlstra 4 2,6 % Rafael J. Wysocki 4 2,6 % Yinghai Lu 4 2,6 % Hugh Dickins 4 2,6 % Alan Stern 4 2,6 % Eric Miao 4 2,6 % Thomas Gleixner 3 2,0 % Lennert Buytenhek 3 2,0 % Alex Chiang 3 2,0 % Krzysztof Helt 3 2,0 % Stefan Richter 3 2,0 % Andy Whitcroft 3 2,0 % KOSAKI Motohiro 2 1,3 % Dennis Jansen 2 1,3 % Andrew Morton 2 1,3 % David S. Miller 2 1,3 %

Shrnuto: Adrian Bunk vyslovil přes 20 % z celkového počtu uznání za nahlášení chyby - sám sobě. Kromě toho si mnoho hlavních vývojářů našlo alespoň nějaký čas k vyslovení uznání těm, kteří chyby hlásili a testovali patche. 10 628 sad změn začleněných do 2.6.27 nicméně pravděpodobně obsahovalo o pár patchů, které by měly příslušné značky nést, víc. Jestliže mají značky o hlášení a testování být skutečně užitečné a významné, měly by být používány mnohem obecněji.

Když už v tom autor článku byl, také vytvořil statistiku značek Reviewed-by: (revidoval). Tyto značky se liší tím, že jsou nabízeny revidovatelem, který jimi prohlašuje, že byla provedena rozumně důkladná revize a v kódu nebyly nalezeny vážné nedostatky. Revize kódu je nedostatkové zboží v každém projektu svobodného softwaru, takže důkladné uznání revidovatelům se zdá být víc než dobrý nápad. Zde jsou nejčastější revidovatelé 2.6.27.

Vývojáři s nejvíce revidováními (celkem 123)
Ingo Molnár	23	18,7 %
Paul Jackson	12	9,8 %
Peter Zijlstra	11	8,9 %
Christoph Lameter	10	8,1 %
Aneesh Kumar K.V	7	5,7 %
KOSAKI Motohiro	6	4,9 %
Paul E. McKenney	6	4,9 %
Jeff Moyer	5	4,1 %
Robert P. J. Day	4	3,3 %
Nadia Derbey	3	2,4 %
Paul E. McKenney	3	2,4 %
Mingming Cao	2	1,6 %
Michael Buesch	2	1,6 %
Li Zefan	2	1,6 %
Matthew Wilcox	2	1,6 %
Ingo Oeser	2	1,6 %
Badari Pulavarty	2	1,6 %

Jestliže lze těmto číslům věřit, bylo ve vývojovém cyklu 2.6.27 provedeno pouze 123 revizí. I ten nejcyničtější pozorovatel pravděpodobně bude souhlasit, že je prováděno o něco víc revizí, než je zde uvedeno. Většina revidovatelů nepřidává danou značku, takže jejich příspěvek není zaznamenán. Konkrétně Andrew Morton, který, zdá se, reviduje téměř všechny patche, které se objeví, by měl být na první příčce výše uvedeného seznamu.

Úkol zajistit vhodné uznání testerům, ohlašovatelům chyb a revidovatelům je zjevně ve svých počátečních fázích. Někde se ale začít musí; i toto je více informací, než jsme měli dříve. Doufejme, že časem se zvyk oceňovat lidi, kteří pomáhají s vývojovým procesem, více rozšíří. A to při troše štěstí podpoří více testování a hlášení chyb a vyústí v lepší jádro.

/dev/ksm: dynamické sdílení paměti

Jádro obecně má ve zvyku sdílet identické stránky paměti mezi procesy. Kód programů je například vždy sdílen. Ale i zapisovatelné stránky jsou sdíleny mezi procesy, pokud jádro ví, že je jejich obsah stejný pro všechny procesy, kterých se to týká. Když proces zavolá fork(), všechny zapisovatelné stránky jsou změněny na kopírovat při zápisu [copy-on-write, COW] a sdíleny mezi rodičem a potomkem. Dokud ani jeden z procesů danou stránku nezmění, sdílení může trvat a s ním i odpovídající úspora paměti.

Copy-on-write u fork() funguje, jelikož jádro ví, že každý proces očekává v daných stránkách stejný obsah. Když to ale jádro neví, obecně není schopné zařídit sdílení identických stránek. Jeden by si mohl myslet, že to běžně nebude problém, ale vývojáři KVM přišli na několik situací, kde by takové sdílení mohlo nastat. Autor článku nemohl odolat tomuto příkladu, který nabídl Avi Kivity:

Vezměme typický víceuživatelský minipočítač s Gnome, na kterém všech 150 uživatelů naráz čte Jaderné noviny místo toho, aby pracovali. Lze sdílet cache vykreslených stránek Firefoxu, což by drasticky snížilo využití paměti.

Kromě takto typických systémů zvažme například hostitele, na kterém běží několik virtualizovaných hostů. Tito hosté nesdílí vztah stromu procesů, což by zjednodušilo sdílení stránek mezi nimi, ale významná část jejich paměti může snadno obsahovat stejná data. Pokud by hostitel mohl najít způsob, jak vynutit sdílení stránek se shodným obsahem, měl by být schopen lépe využít svou paměť a díky tomu umožnit běh více hostů. To je věc, která přitahuje pozornost vývojářů virtualizace. Programátoři v Qumranetu Red Hatu (Izik Eidus, Andrea Arcangeli a Chris Wright konkrétně) tedy dali dohromady mechanismus, který takové sdílení umožňuje. Výsledný kód nazvaný KSM byl nedávno zaslán pro širší revidování.

KSM má podobu ovladače zařízení pro jediné virtuální zařízení: /dev/ksm. Proces, který se chce účastnit režimu sdílení stránek, může toto zařízení otevřít a registrovat (ioctl() voláním) část svého adresového prostoru v KSM ovladači. Když je mechanismus sdílení stránek zapnut (dalším ioctl()), jádro začne hledat stránky, které lze sdílet.

Algoritmus je relativně jednoduchý. KSM ovladač v jaderném vlákně vezme jednu z registrovaných oblastí paměti a začne ji prohledávat. Pro každou stránku, která je rezidentní v paměti, KSM vygeneruje SHA1 hash jejího obsahu. Hash se následně použije pro vyhledávání stránek se stejnou hodnotou hashe. Pokud následné memcmp() ukáže, že obsahy stránek jsou skutečně identické, každý proces odkazující na prohledávanou stránku bude (v COW režimu) odkázán na jinou a redundantní stránka je vrácena systému. Dokud nikdo stránku nemodifikuje, sdílení může pokračovat; jakmile proběhne operace zápisu, stránka je zkopírována a sdílení zrušeno.

Jaderné vlákno prohledá až stanovený maximální počet stránek a potom se na chvíli uspí - maximální počet stránek k prohledání a doba uspání jsou předány jako parametry ioctl() volání, které prohledávání začne. Řídící proces v uživatelském prostoru může prohledávání také pozastavit dalším ioctl() voláním.

První reakce na patch od Andrewa Mortona nebyla moc nadšená:

Celý tento přístup mi přijde špatný. Jádro tyto stránky přestalo sledovat a my se to teď post facto snažíme napravit. Prosím vysvětli (v changelogu), proč to jádro nemůže dělat správně pomocí běžného sdílení, počítání odkazů a COW.

Odpověď Aviho Kivityho je rozumně jasná:

U kvm jádro nikdy nevědělo, že jsou tyto stránky sdílené. Jsou nahrány z nezávislého (možná komprimovaného a zašifrovaného) obrazu disku. Tyto obrazy jsou různé; nicméně některé stránky jsou stejné, protože pochází ze stejného instalačního média.

Izik Eidus dodává, že s tímto patchem byl hostitel provozující několik Windows hostů schopen zavázat se [overcommit] k poskytnutí 300 % své paměti bez hrozných následků. Tato technika je u Windows hostů zjevně obzvlášť účinná: Windows zjevně nulují veškerou uvolňovanou paměť, takže seznam volných stránek všech hostů může být shromážděn do jediné sdílené stránky plné nul.

Co ještě nebylo provedeno (nebo minimálně zasláno), je nějaký benchmark toho, jaký dopad by měl KSM na běžící systém. Prohledávání, hashování a porovnávání stránek vyžaduje nějaký čas CPU a bude mít pravděpodobně významný vliv na cache. Jestliže provozujete několik tuctů Windows hostů, vliv na cache může být relativně nízko na vašem seznamu. Tato cena nicméně může být dostatečná k tomu, aby se KSM nepoužívalo obecněji, i když i systémy, které virtualizaci nepoužívají, mohou mít mnoho stránek s identickým obsahem.

Smutný příběh ovladače em28xx

Během posledních dvou let se vývojový proces změnil s úmyslem zjednodušit přidávání nových ovladačů. Prokázalo se, že ovladače mimo strom se často nijak nezlepší, dokud nejsou začleněny; uživatelé nicméně tyto ovladače chtějí a distributoři je dodávají. Zdá se tedy, že zájmy všech jsou uspokojeny tím, že se tyto ovladače dostanou do hlavní řady, dostane se jim více pozornosti a většinou se rychle zlepší.

Vzhledem k tomu je s podivem, proč nedávno zaslaná série ovladačů "empia" Markuse Rechbergera narazila na tolik odporu. Ovladač pracuje s mnoha zařízeními pro zachytávání videa, která jsou založena na čipech Empia; hodně z nich jádro nyní nepodporuje. Jako zaměstnanec Empia Technology má Markus přístup k relevantním datasheetům, a je proto vhodným kandidátem pro napsání plně funkčního ovladače. Najdou se uživatelé, kteří potvrdí, že ovladače fungují a Markus poskytuje dobrou podporu. Nicméně, jak se nyní zdá, tento ovladač do hlavní řady jádra nemíří.

Máme tu klasický případ impedančního nepřizpůsobení mezi vývojářem a komunitou vývojářů. Tento dlouhý příběh pomohl dát vývojářské komunitě Video4Linux tak trochu reputaci nefunkční rodiny - teprve teď se toho vývojáři pomalu zbavují. Zdá se, že smutná pravda je ta, že spolupracovat s komunitou je něco, co několik tisíc vývojářů každoročně zvládne bez větších potíží, ale vždy se najde pár těch, kteří s tím mají problémy.

Na místě je rychlé shrnutí historie. Markus byl jedním z autorů původního ovladače em28xx, který byl poprvé začleněn do jádra 2.6.15. Jeho snahy ho vylepšit nicméně rychle narazily na problémy, když se pokusil o významné změny nízkoúrovňového rozhraní tuneru - o změny, které ovlivnily mnoho dalších ovladačů. Tyto změny se komunitě Video4Linux nelíbily - existovaly obavy, že by mohly poškodit jiné ovladače. Kód tedy nebyl začleněn.

V reakci na toto odmítnutí Markus prohlásil, že ovladač em28xx je v jeho vlastnictví a žádal jeho odstranění z hlavní řady jádra. Dále potom pokračoval ve vývoji kódu a hostoval ho na vlastním serveru. Dokonce bylo období, kdy byl kód přelicencován na MPL, zjevně jako snaha zabránit jeho převzetí do hlavní řady. Markus nakonec přišel s novým přístupem, který přesunul velkou část kódu tuneru do uživatelského prostoru. Toto řešení také neprošlo revizí; nikdo jiný neviděl výhodu v přesunutí tak velké části kódu ovladače mimo jádro. Fakt, že Markus měl zjevně v úmyslu distribuovat část tohoto kódu pouze v binární podobě, zde vůbec nepomohl. Přístup v uživatelském prostoru stejně jako jeho předchůdce začleněn nebyl.

Zatímco Markus pracoval na své verzi kódu, ostatní přidávali patche do ovladače em28xx v hlavní řadě. Čas od času se Markus snažil tyto změny zablokovat. Tón diskuze lze pravděpodobně nejlépe vidět z tohoto dopisu zaslaného správci Video4Linux Mauro Carvalho Chehabovi:

Nejlepší by bylo nahradit tě jako správce někým jiným, protože ani ty nemáš žádný respekt k práci jiných. Firmy by si měly dávat pozor na to, že když ti pošlou nějaký kód, ztratí vládu nad svou prací.

Ztráta "vlivu" na kód je samozřejmě automatická ve chvíli, kdy je tento kód vydán pod licencemi jako GPL. Tento pokus zajistit si kontrolu nad svobodně licencovaným kódem byl zastaven Andrewem Mortonem a dalšími, ale zanechal za sebou nepříjemné vzpomínky.

Nyní je Markus zpátky s ovladačem, který podle všeho duplikuje funkci ovladače, který již v hlavní řadě jádra je. Za tímto zasláním není těžké vidět nový pokus o převzetí kontroly nad tím ovladačem a možná znovu začít diskuzi z minulých let. Není tedy příliš překvapující, že ovladač nebyl přijat s velkým nadšením. V krátkosti bylo Markusovi řečeno, že pokud nechce zasílat svou práci v podobě série malých patchů k ovladači em28xx ve stromě, má jít pryč. To je také způsob, jaký se od vývojářů jádra běžně očekává. Na druhou stranu, video vývojář Hans Verkuil revidoval nový ovladač a shrnul:

Podle mého názoru je vcelku beznadějné snažit se konvertovat současný ovladač em28xx na to, co máš ty. Znamená to obrovské množství práce, kterou nikdo nechce dělat a (v tomto případě) to má velmi malý přínos.

Nehledě na tuto revizi Mauro naznačil, že nemá zájem tento patch akceptovat. Okamžité odmítnutí Markusova nového ovladače by ale mohla být chyba. Není téměř pochyb, že se vyvinul dál než ovladač ve stromě; podporuje větší škálu zařízení. Nezačlenit ho znamená riziko ztráty práce, která na něm byla udělána, a možná i ztráty budoucí práce od vývojáře, který se přes všechny své chyby snaží poskytnout lepší služby uživatelům Video4Linux.

Mít pro stejný hardware v jádře více ovladačů není ideální situace, ale také to není bezprecedentní. Subsystémy IDE a parallel ATA poskytují redundantní podporu pro velkou škálu hardwaru. Ovladače e1000 a e1000e se po nějaký čas překrývaly. V takovém případě bývá dlouhodobým cílem pracovat na odstranění jednoho z ovladačů.

Dalo by se tedy přimlouvat za začlenění nového ovladače a časem za odstranění starého. Během tohoto procesu by nový ovladač mohl obdržet tolik potřebnou pozornost ostatních vývojářů. Má problémy se stylem kódu a přiznáváním copyrightů [copyright attribution]; po rychlé revizi autor tohoto článku také dumal nad problémy se zamykáním. Takové problémy jsou ale pro ovladače, které strávily mnoho času mimo strom, běžné; je to prostě něco, co je potřeba opravit. I tak ale tento ovladač obsahuje výsledek roků práce a přístup k relevantním datasheetům; jeho zmrazení asi není v nejlepším zájmu ani uživatelů, ani vývojářů jádra.

       

Komentáře

[trekker.dk]

To KSM vypadá pěkně, ale KSM runs into patent trouble

Zajímalo by mě, proč se do jádra nemůžou dostat věci, které jsou protiprávní jenom pro ty [doplň urážku] Američany a třeba tady v Evropě s nimi není problém.

[Michal Vyskočil]

Zajímalo by mě, proč se do jádra nemůžou dostat věci, které jsou protiprávní jenom pro ty [doplň urážku] Američany a třeba tady v Evropě s nimi není problém.

Že by značná část lidí schopných to tam dát (a nechat) pro ty [doplň urážku] Američany pracovala?

[trekker.dk]

No nevím - co by se tak mohlo stát někomu, kdo by nechal začlenit do jádra kód, který (ve většině případů) je patentován buď konkurencí zaměstnavatele nebo dokonce firmou, se kterou si zaměstnavatel ani nekonkuruje, protože se zabývá něčím jiným.

[Mordae]

V pohode, uz nasli "prior art", jen ted nejak vymyslet jak to poresit mimosoudne. Ale stejne je zrizeni v USA zapachajici hromada cehosi.

[Aleš Kapica]

Shrnuto: Adrian Bunk vyslovil přes 20 % z celkového počtu uznání za nahlášení chyby - sám sobě.

Proč se nepochválit za to že jsem našel nějakou chybku, když to nikdo jiný za mě neudělá, že? Ale vážně. Ta poznámka jako odlehčení tématu opravdu nebyla špatná.

[geebranz]

embedded words

storageshedsalbuquerquenm.com

[geebranz]

That's true

storageshedsevansville.com