Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel

23.7. | Jirka Bourek | Jaderné noviny | 4190×

Aktuální verze jádra: 2.6.35-rc4. Citáty týdne: Dave Airlie, Rusty Russell. Ptejte se jaderného vývojáře. O škálovatelnosti Linuse. Příliš mnoho přetažení?

Obsah

• Aktuální verze jádra: 2.6.35-rc4
• Citáty týdne: Dave Airlie, Rusty Russell
• Ptejte se jaderného vývojáře
• O škálovatelnosti Linuse
  • Příliš mnoho přetažení?

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

Současné vývojové jádro je 2.6.35-rc4 vydané 4. července. Už týden jsem zase online a soudě podle patchů a požadavků na přetažení, které dostávám, musím říct, že když jsem byl u -rc3 striktní, fungovalo to poměrně dobře. Diffstat mezi rc3 a rc4 vypadá docela rozumně i přes delší okno mezi -rc. A i když se rozhodně objevily věci, které potřebovaly opravit, doufám, že i přes mou dovolenou vyjde 2.6.35 včas […] Co se detailů týče, k dispozici jsou zkrácený changelog i kompletní changelog.

Stavidla stabilních jader se otevřela a vyplaveno bylo pět různých stabilních jader: 2.6.27.48, 2.6.31.14, 2.6.32.16, 2.6.33.6 a 2.6.34.1. Žádná další jádra 2.6.31 nebudou a pro vydání 2.6.33 vyjde už jenom jedna aktualizace. Ostatní budou ještě nějaký čas aktualizována.

Citáty týdne: Dave Airlie, Rusty Russell

Takže jaderné kousky jste dostali do upstreamu a dobré kousky pro uživatelský prostor si necháváte pro sebe, leží vám na klíně a hladíte si je jako Dr. Zlo. Proč by jaderní správci měli tohle břemeno přebírat, když jim nechcete dát to, co opravdu potřebují ke zprovoznění svého hardwaru?

-- Dave Airlie

Poznámka: Když respektované zdroje informací mluví o něčem, s čím máte opravdu dobré zkušenosti, výsledkem je často to, že přemýšlíte, kolik výkalů jste jim zbaštili v oblastech, ve kterých se nevyznáte.

-- Rusty Russell

Ptejte se jaderného vývojáře

Originál tohoto článku pro lwn.net napsal Greg Kroah-Hartman.

Jeden sloupek ze série, ve které se ptáte vývojáře jádra a on se snaží vaše dotazy zodpovědět. Pokud máte nějaké nezodpovězené dotazy ohledně technických nebo procedurálních záležitostí linuxového jádra, můžete je položit v sekci pro komentáře u originálu článku, nebo je zaslat e-mailem přímo autorovi.

Jak zjistím, komu napsat o problému, který mám s jádrem. V jaderném logu vidím různé zprávy, jak podle nich poznám, který vývojář mi může pomoci?

Například teď vidím následující chybu:

[  658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:
[  658.831702] 48 48 48 48 50 50 50 50 20 20 20 20 4c 4c 4c 4c HHHHPPPP    LLLL
[  658.831705] 50 50 50 50 33 33 33 33 30 30 30 30 36 36 36 36 PPPP333300006666
[  658.831709] 35 35 35 35 0a 0a 0a 0a 20 20 20 20 20 20 20 20 5555…

Kde mám začít, abych problém dohledal?

Jaderný log ti říká, kde je problém, takže trik spočívá v tom zjistit, kdo je za zprávy zodpovědný. Jsou různé způsoby, jak na to. Nejprve můžeš zkusit grepovat zdrojové kódy jádra a hledat chybovou zprávu:

$ cd linux-2.6
$ git grep "\*ERROR\* Raw EDID"

Ok, to nic neudělalo, takže zkusíme řetězec trochu zkrátit:

$ git grep "Raw EDID"
drivers/gpu/drm/drm_edid.c:            DRM_ERROR("Raw EDID:\n");

Ok, teď máš soubor, do kterého se můžeš podívat. Ale kdo je za něj odpovědný? Jak bylo zmíněno dříve, můžeš použít skript get_maintainer.pl, kterému předáš jméno souboru, který tě zajímá:

$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/drm_edid.c
David Airlie <airlied@linux.ie>
Dave Airlie <airlied@redhat.com>
Adam Jackson <ajax@redhat.com>
Zhao Yakui <yakui.zhao@intel.com>
dri-devel@lists.freedesktop.org
linux-kernel@vger.kernel.org

To nám ukázalo, že nejlepší osoba, které se zeptat, je hlavní vývojář DRM David Airlie, ale pomoci by mohli i další vývojáři. Když pošleš e-mail Davidovi a do CC přidáš ostatní zmíněné (včetně e-mailových konferencí), dostane se těm, kteří by nejpravděpodobněji mohli pomoci.

Další možnost, jak zjistit, který kód je za problém zodpovědný, je podívat se na jméno funkce, která chybu vypisuje:

[  658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:

Jméno funkce je uzavřeno v závorkách [] a můžeme se podívat, který kód ji volá:

$ git grep edid_is_valid
drivers/gpu/drm/drm_edid.c: * drm_edid_is_valid – sanity check EDID data
drivers/gpu/drm/drm_edid.c:bool drm_edid_is_valid(struct edid *edid)
drivers/gpu/drm/drm_edid.c:EXPORT_SYMBOL(drm_edid_is_valid);
drivers/gpu/drm/drm_edid.c: if (!drm_edid_is_valid(edid)) {
drivers/gpu/drm/radeon/radeon_combios.c:    if (!drm_edid_is_valid(edid)) {
include/drm/drm_crtc.h:extern bool drm_edid_is_valid(struct edid *edid);

To opět ukazuje, že za chybovou zprávu je odpovědný soubor drivers/gpu/drm/drm_edid.c.

Když se podíváme na funkci drm_edid_is_valid, před touto zprávou jádro mohlo vypsat i další:

if (csum) {
        DRM_ERROR("EDID checksum is invalid, remainder is %d\n", csum);
        goto bad;
}

if (edid->version != 1) {
        DRM_ERROR("EDID has major version %d, instead of 1\n", edid->version);
        goto bad;
}

Když tedy posíláš e-mail vývojářům a do e-mailových konferencí, které jsi našel skriptem get_maintainer.pl, je vždy důležité poskytnout všechny jaderné logy, ne jenom několik posledních řádek chyby, protože o něco výše může být víc informací, které mohou vývojáři použít pro odladění problému.

[Za zaslání této otázky díky Peteru Favrholdtovi.]

O škálovatelnosti Linuse

napsal Jonathan Corbet, 2. července 2010

Vývojový proces Linuxu v mnoha ohledech vyniká; jedním z nich je fakt, že do „oficiálního“ repozitáře kód vkládá právě jedna osoba. O různé subsystémy se stará mnoho různých správců, ale každý patch, který tito správci začlení, musí nakonec přijmout Linus Torvalds, pokud se má dostat do hlavní řady. Linusova unikátní role tento proces mnoha způsoby ovlivňuje; například nyní, když je tento článek sepisován, se Linus právě vrátil z dovolené, která vedla k tomu, že do hlavní řady nebylo pár týdnů začleňováno nic. S tímto modelem jediného vkladatele kódu jsou však spjaty mnohem vážnější záležitosti, přičemž škálovatelnost se pohybuje na čelních pozicích.

Někteří čtenáři Jaderných novin si určitě vzpomenou na vydání 2.1.123 v září 1998. Toto jádro se nedalo zkompilovat, protože Linus začlenil jenom část patchů pro framebuffer. Selhání překladu vývojového jádra nevypadá jako žádná velká krize, ale tato chyba se stala bodem, ve kterém se vybil vztek hromadící se v komunitě vývojářů: Patche byly čím dál tím více zahazovány a lidi to unavovalo. Na konci dlouhé a nepříjemné diskuze Linus rozhodil rukama a šel pryč:

Abych byl upřímný, tato diskuze (a jiné před ní) mě jenom naštvaly a ZVYŠUJE to tlak na mě. Jestli máte problém s tím, jak pracuju s patchi, navrhuju vám, abyste se na pět minut zamysleli nad tím, s čím se musím potýkat.

Jděte pryč, lidi. Nebo mě aspoň nedávejte do Cc. Nemám zájem, beru si dovolenou a nechci o tom nic víc slyšet. Ve zkratce: Vypadněte z mojí schránky.

Samozřejmě se jedná o slavnou epizodu „Linusova vyhoření“ z roku 1998 (pozn. redakce: vizte článek Hořet, ale nevyhořet). Na chvíli se všechno zastavilo, dokud si Linus trochu neodpočinul, nevrátil se a nezačal opět začleňovat patche. Věci se opět trochu přiostřily roku 2000, což vedlo k trochu svatouškovské přednášce o prokletí nadaných od Erica Raymonda. Roku 2002, když se pracovalo na řadě 2.5, frustrace ze zahozených patchů opět vzrostla; základem pro další dlouhý flamewar o nefunkční podobě vývojového procesu jádra a o problému „Linus neškáluje“ byl tenkrát návrh „patchujícího tučňáka“ Roba Landleyho.

Krátce poté se věci mnohem zlepšily. Není pochyb o tom, co je změnilo: Přijetí BitKeeperu – přes všechny flamewary, které kvůli tomu vznikly – zajistilo, že vývojový proces jádra začal fungovat. Přechod ke Gitu věci vylepšil ještě více; ukazuje se, že se správnými nástroji Linus škáluje velmi dobře. V roce 2010 zvládá takový objem patchů, který by tenkrát byl nemyslitelný, a vývojový proces přitom funguje velice hladce.

Autor článku má nicméně obavu, že se na horizontu objevují mraky; blíží se další bod, kde se narazí na Linusovu škálovatelnost? V cyklu 2.6.34 Linus zavedl politiku nepředvídatelné délky začleňovacího okna – i když se zatím jednalo spíše o řeči než o činy. V případě 2.6.35 poměrně dost vývojářů zůstalo, co se požadavků na přetažení [pull request] týče, bez odezvy; Linus se je prostě rozhodl ignorovat. Výbuch ohledně architektury ARM toho byl součástí, ale nebyly přetaženy i další stromy. Do těch špatných dní, kdy patche jednoduše mizely v prázdnotě, jsme se nevrátili a Linus možná jenom trochu experimentuje s vývojovým procesem, aby některé správce vybídl k jinému chování. I tak ale tiché ignorování požadavků na přetažení vyvolává špatné vzpomínky z té doby.

Příliš mnoho přetažení?

V typickém vývojovém cyklu je do hlavní řady začleněno více než 10 000 změn. Linus se však většiny těchto patchů nedotýká: Místo toho je přetahuje ze stromů, které spravují správci subsystémů. Kolik pozornosti je věnováno specifickým požadavkům na přetažení, není zcela jasné; na každý se Linus dívá dostatečně zblízka, aby se ujistil, že je v něm to, co mu řekl správce. Některá přetažení jsou zjevně podrobena bližšímu zkoumání, zatímco jiná projdou jenom s krátkou prohlídkou. I tak je jasné, že každý požadavek na přetažení a každý patch vyžaduje nějakou pozornost a přemýšlení, než je začleněn.

Následující tabulka shrnuje Linusovu začleňovací aktivitu pro posledních deset verzí jádra (řádka 2.6.35 odráží stav do 2.6.35-rc3):

Verze	Přetažení		Patche
	Začleňovací okno	Celkem	Přímo	Celkem
2.6.26	159	426	288	1496
2.6.27	153	436	339	1413
2.6.28	150	398	313	954
2.6.29	129	418	267	896
2.6.30	145	411	249	618
2.6.31	187	479	300	788
2.6.32	185	451	112	789
2.6.33	176	444	104	605
2.6.34	118	393	94	581
2.6.35	160	218	38	405

Dva sloupce pod „přetažení“ ukazují počet stromů, ze kterých se přetahovalo během začleňovacího okna a během vývojového cyklu jako celku. Je potřeba říci, že tato čísla mohou být příliš malá, protože začleňování „rychle vpřed“ [fast-forward] v historii gitu nemusí ponechávat žádné stopy. Linus ale dělá jenom málo začlenění „rychle vpřed“, takže počet přehlédnutých začlenění bude malý, pokud vůbec nějaká budou.

Linus také některé patche začleňuje přímo. Většina z nich pochází od Andrewa Mortona, který k předávání patchů Linusovi nepoužívá git. V tabulce výše sloupec „celkem“ zahrnuje změny, které přišly od Andrewa, zatímco sloupec „přímo“ počítá pouze patche, se kterými nepracoval Andrew.

Z této tabulky jsou zjevné trendy: Počet patchů, které jdou přímo do hlavní řady, významně poklesl; téměř všechno nejprve prochází přes něčí strom. Na Linuse v tomto okamžiku zbývá povětšinou jenom označování verzí, urgentní opravy a reverty. Andrew Morton zůstává pro velkou část jádra správcem poslední záchrany, ale čím dál tím více změny neprochází ani přes jeho strom. Počet přetažení přitom zůstává přibližně stejný. Bylo by zajímavé zamyslet se nad tím, proč to tak je.

I přes rostoucí počet stromů možná není potřeba víc přetažení. A nebo se blížíme přirozenému limitu toho, kolika požadavkům na přetažení ze subsystému dokáže jeden talentovaný benevolentní diktátor věnovat pozornost, aniž by vyhořel. Konec konců dává rozum, že počet požadavků, které Linus zpracuje, se nemůže neomezeně zvyšovat; jestliže jaderná komunita dál poroste, musí se zde zákonitě objevit úzké hrdlo škálovatelnosti. Zůstává jediná otázka, kdy by to mohlo nastat.

Pokud zde máme oprávněné obavy, mohlo by stát za to zamyslet se nad reakcí dříve, než se věci zase rozbijí. Jedním ze zjevných přístupů by mohlo být změnit fakt, že jsou téměř všechny stromy přetahovány přímo do hlavní řady; na obrázku vpravo můžete vidět, jak plochá je tato struktura u 2.6.35. Správci subsystémů, kteří si vysloužili dostatečnou důvěru, by mohli řešit více požadavků na přetažení z nižší úrovně a výsledek předložit Linusovi s tím, že ho může začlenit s relativně malými starostmi. Subsystém síťování takto již funguje; mnoho stromů plní strom síťování Davida Millera předtím, než jsou patche zaslány výše. Na druhou stranu různé tlaky vedly k tomu, že na straně architektury ARM dochází k opačnému procesu: Nyní je zde několik stromů subarchitektur, které jdou přímo Linusovi. Počet přetažení u ARM se zjevně stal Linusovou motivací pro ukončení začleňovacího okna 2.6.35.

Další řešení by bylo dát dalším lidem moc vkládat stromy přímo do hlavní řady. Není ale jisté, jestli je někdo připraven na takto radikální změnu ve vývojovém procesu jádra. A varování Teda Ts'o z roku 1998 všem, kteří by si přáli model „vnitřního týmu“, stojí za přečtení i po dvanácti letech.

Jestliže si ale Linus ponechá svou pozici ve vývoji Linuxu pouze pro sebe, komunita jako celek bude muset zajistit, že proces jako takový bude škálovat a nezaplaví ho. Zajistit, aby více začlenění probíhalo před tím, než se kód dostane k Linusovi, vypadá jako přístup se slibným potenciálem, ale autor článku se doslechl, že Linus není moc nakloněn přílišnému slučování stromů; chce si věci na cestě do hlavní řady prohlédnout. I tak ale musí být místa, kde by to fungovalo. Možná potřebujeme strom, který by zase zastřešil celou architekturu ARM, a možná by mohlo být místo pro strom, kde by se shromažďovaly patche pro většinu ovladačů.

Linuxové jádro a jeho vývojový proces je mnohem větší než roku 2002. Pokud by se tento proces měl znovu zadrhnout kvůli problémům se škálovatelnosti na vrcholu, důsledky by byly mnohem viditelnější veřejnosti. I když tu není nebezpečí akutních potíží, neměli bychom se plynulostí, s jakou se pracovalo posledních několik let, nechat ukolébat k tomu, že se nic podobného nemůže stát. Stejně jako u kódu samotného je dobré myslet na problémy se škálovatelností dříve, než udeří.

       

Komentáře

[pc2005]

Ad přetížení Linuse: Tak udělat dalšího správce na úrovni Linuse a decentralizovat. Akorát nevím zda by se pak neporvali .

[poky74]

To si nedovedu dost dobře představit. Že by každý dělal půlku práce? To je nesmysl. Vanilkové jádro je jen jedno, proto je pro něj nejlepší když se o něj stará právě jeden člověk.

[pc2005]

Tam bylo napsaný, že Linus musí každý patch signovat (a tedy asi i zkontrolovat), tohle by klidně šlo rozdělit mezi více osob. Prostě by se věřilo třeba Adrew Mortonovi stejně jako Linusovi. Určitě z těch patchů za jádro nejsou všechny na sobě závislé, takže by šlo jejich příjem a kontrolu zparalelizovat (prostě make -j 2 sign oproti make -j 1 sign ).

[JoHnY2]

Ja osobne si nemyslim, ze by mel existovat nekdo na urovni Linuse. Projekt jako celek podle me vzdycky potrebuje jednoho cloveka, kterej proste rekne "Udelame to takhle!". Navic u Linuse je velka vyhoda v tom, ze ho nikdo nemuze zpochybnovat nebo se sapat na jeho misto. On proste sedi na spicce pyramidy a hotovo.

Docela by me zajimalo kolik patchu vazne potrebuje dohled od Linuse a kolik je pro nej jen rutinni zalezitost, kde neni moc co vymejslet, protoze zakladni praci udelal spravce subsystemu.

[pc2005]

kterej proste rekne "Udelame to takhle!"

Ovšem jen pokud pak neříká: "nestíhám!". Složitost jádra roste imho dost silně je klidně možný, že brzy překročí stav, kdy ho jeden člověk už nezvládne sledovat.

a kolik je pro nej jen rutinni zalezitost

No a právě tady by to za něj mohl dělat někdo jinej a ušetřit drahé Linuso-hodiny .

[π]

to jako myslíš fork? :P

[Aleš Kapica]

Momentálně slaví Linux kulaté 20-leté výročí. Zaregistroval to z vás vůbec někdo?.

Jak píšu ve svém blogpostu z 20.7.2006 Až Linus zaklepe na nebeskou bránu.... Je to prozatím víceméně generační záležitost. Po čtyřicítce začíná opět stoupat pravděpodobnost že člověk znenadání natáhne brka. Soudě dle výše uvedeného textu nejsem sám, kdo si říká, že by současný začleňovací model měl být poněkud zkorigován.

[Jendа]

Snad 19leté, ne?

[pc2005]

Jo taky bych řekl a ani ne dneska:

První verze linuxového jádra (0.01) byla na Internetu zveřejněna 17. září 1991.

odsud.

P.S. Já to vždycky zaregistruju až ze zpráviček tady .

[Aleš Kapica]

25.8.1991 - neznámý finský student Linus Benedict Torvalds zaslal do diskuzní skupiny comp.os.minix příspěvek s předmětem "What would you like to see most in minix?". O tom, že vyrábí free operační systém - nic komerčního a velkého, pouze jen tak ze zábavy.

Rozdíl je v tom, že pro vás je podstatný porod, kdežto pro mne početí..

[trekker.dk]

2010 - 1991 = ?

[Aleš Kapica]

On je ještě rok 2010? A sakra..

[pc2005]

Jenže v tom případě jsem počal tak milion projektů (ovšem zřejmě je nikdy nedokončím ).

pro vás je

P.S. Pokud to není do publika, tak >patička<.

[kip]

Neměl být v citátu Dava Airlieho spíš "Dr. Zloun" (z Austina Powerse)?

[tsLnox]

Doktor Zlo z Bugemose je lepší :-P

[Zopper]

Asi ano.... Ale překladatel možná zná http://www.bugemos.com/?q=taxonomy/term/13 - tady je Dipl. Ing. F. Zlo, M.B.A., sice to není Dr., ale to nevadí :D

[David Jaša]

Na Dr. snad bylo habilitováno jeho jednovaječné dvojče, D. Zlo.

[Honza]

I vyhořelé palivo se dá zpracovat...

[the já]

Lol cože

[Jendа]

Co do svého oblíbeného vyhledávače zadat zpracování vyhořelého paliva? Dobré by bylo s tím ohřívat vodu pro ústřední topení .

[imploder]

Vyhořelým Linusem?

[Bubak]

Je to jenom strom. Kdyz kvalita Linusova stromu klesne, proste se vyvoj rozstepi a pozdeji slouci na jinem strome. Navic ani Linus nema absolutni pravo veta, jak dokazuji modifikovana jadra v distribucich a Android.

[lok]

Jiz se tesim, az nektere z Linusovych deti (myslim ze nejake ma, nevim kolik a jake), provede forknuti Linuxu a tatinek s potomkem si budou vesele konkurovat.

[poky74]

Má jen tuším 2 holky, šance že by šli ve šlépějích otce je mizivá, ale zajímavé by to bylo :)

[pc2005]

Linuxačky s černým pásem v karate, to by bylo něco.

[imploder]

To mi připomnělo xkcd: 1337