Jaderné noviny – 7. 9. 2012: Ulehčení života distribucím

24. 9. 2012 | Luboš Doležel

Články - Jaderné noviny – 7. 9. 2012: Ulehčení života distribucím  

Aktuální verze jádra: 3.6-rc4. Citáty týdne: The Economist, Andrew Morton, Steven Rostedt, Alan Cox. Jaderný summit 2012: Regresní testování: Trinity: inteligentní fuzz testing; Regresní benchmarky. Jaderný summit 2012: Distribuce a upstream.

Obsah

• Aktuální verze jádra: 3.6-rc4
• Citáty týdne: The Economist, Andrew Morton, Steven Rostedt, Alan Cox
• Jaderný summit 2012: Regresní testování
  • Trinity: inteligentní fuzz testing
  • Regresní benchmarky
• Jaderný summit 2012: Distribuce a upstream

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

Aktuální vývojová verze jádra je 3.6-rc4 vydaná 1. září. Seznam změn čtěte níže, jak můžete vidět, jsou to jen nahodilé věci. Doufám, že se tím dostáváme do nudných/stabilních -rc a nerozjede se to jen kvůli tomu, že se lidé vracejí domů.

Stabilní aktualizace: poslední týden žádné nevyšly a ani se žádné nerevidují.

Citáty týdne: The Economist, Andrew Morton, Steven Rostedt, Alan Cox

Jak jistě každý rodič ví, uklizený pokojíček je od neuklizeného dosti odlišný. Počet věcí v místnosti může být přesně stejný, ale rozdíl mezi řádným a neřádným uspořádáním věcí je hned zjevný. Tak a teď si představte dům s milionem místností, kdy každá je buď uklizená nebo neuklizená. Robot může v domě zkontrolovat každý pokoj, aby zjistil, v jakém stavu je. Také může z uklizeného pokoje udělat neuklizený (náhodným pohazováním věcí) a z neuklizeného uklizený (úklidem). To je v podstatě to, jak funguje nová generace paměťových čipů.

-- The Economist na téma PRAM

Z „RFC“ mám vždy obavy. Čtu to jako „Really Flakey Code“ (opravdu ujetý kód).

-- Andrew Morton

Omlouvám se za opožděnou odpověď, byl jsem zaneprázdněn pitím s ostatními jadernými vývojáři, přičemž jsem se vám všem posmíval, že pracujete.

-- Steven Rostedt

Ano, už jsem si pročetl jadernou bugzillu, každý otevřený bug (a přes polovinu jsem uzavřel). Zajímavé to čtení, záhady, nad kterými by zoufal i Sherlock Holmes, obsáhlé, že by se tomu hodil nějaký redaktor, zajímavý prvek do společenských debat, trocha zbytečných vulgarit. Na četbu to ale není moc dobře strukturované a schází tomu vysvětlivky.

-- Alan Cox

Jaderný summit 2012: Regresní testování

Na Jaderném summitu v bloku o regresním testování zazněly přednášky od Dave Jonese a Mela Gormana. Davova prezentace popisovala jeho nový nástroj pro fuzz testing, zatímco Mel se zaobíral zlepšováním benchmarků s cílem odhalovat regrese.

Trinity: inteligentní fuzz testing

Dave Jones hovořil o testovacím nástroji, na kterém pracoval uplynulých 18 měsíců. Tento nástroj, zvaný Trinity, je určitým druhem fuzz testeru systémových volání. Dave poznamenal, že fuzz testing není nic nového a linuxová komunita prováděla všelijaký fuzz testing asi posledních 10 let. Problémem dřívějších fuzz testerů je relativně jednoduchý přístup, tedy předávání náhodných bitů v argumentech systémových volání. To postačuje k odhalení opravdu jednoduchých chyb, například v detekci, že číslená hodnota předaná jako argument s deskriptorem souboru neodpovídá platnému otevřenému deskriptoru. Jakmile jsou tyto chyby opraveny, pak už tyto testery jen dostávají chybové kódy (EINVAL, EBADF apod.), které systémová volání (správně) vracejí, když dostanou nesprávné argumenty.

Trinity se odlišuje tím, že má v sobě určitou inteligenci v dané oblasti. Nástroj obsahuje anotace, jež popisují argumenty očekávané každým ze systémových volání. Například, pokud systémové volání očekává argument s deskriptorem, pak Trinity namísto předávání náhodných čísel otevírá různé druhy souborů a předává takto vzniklé deskriptory. Tím se dostává za jednoduché testy ověřující vstupní argumenty a hledá chyby schované hlouběji. Pomocí anotací se dají popsat různé typy argumentů, včetně adres v paměti, cest v souborovém systému, PIDů, délek a tak dále. Díky anotacím může Trinity generovat testy, které se lépe zaměřují na typ argumentu (web Trinity například říká, že čísla o hodnotě mocniny dvou plus nebo mínus jedna jsou často dobrá k vyvolání chyb ve zpracování argumentů určujících „délku“). Výsledné testy jsou mnohem sofistikovanější než tradiční fuzz testery a nacházejí nové druhy chyb v systémových voláních.

Ted Ts'o se zeptal, jestli je možné zaměřit testy v Trinity na určitý jaderný subsystém. V reakci na to Dave poznamenal, že v Trinity je možné nasměrovat otevírání deskriptorů, které se pak používají, na konkrétní souborový systém (například na oddíl s ext4).

Dave prohlásil, že Trinity pravidelně spouští proti stromu linux-next a také proti Linusovu stromu. Upozornil, že Trinity už našlo chyby v síťovém kódu, kódu souborových systémů a v dalších částech jádra. Jedním z cílů jeho přednášky bylo pošťouchnout vývojáře k tomu, aby sami začali Trinity používat k testování svých subsystémů a architektur. Trinity aktuálně podporuje architektury x86, ia64, powerpc a sparc.

Regresní benchmarky

Mel Gorman se zaměřoval hlavně na lepší odhalování regresí ve výkonu. Řekl, že v minulosti jsme hovořili o benchmarkování patchů při jejich začleňování. Časem se ale objevila spousta nekonzistencí. Zejména pak poukázal na zvyk psát do změn v commitu statistiku z konkrétního nástroje pro benchmarky jako věc pro sledování regresí naprosto nepoužitelnou.

Mel by v přehledech změn commitů rád viděl informace použitelné ke spouštění reprodukovatelných benchmarků. Šel příkladem; Mel má svůj vlastní framework na benchmarky MMTests a zaslal přehled výsledků za jádra 2.6.32 až 3.4. Rád by v seznamu změn viděl kromě výsledků i informace o benchmarku samotném včetně údajů o jeho nastavení.

H. Peter Anvin odpověděl slovy: Doufám, že ti je jasné, že pro autory je těžké dodat vůbec nějaká skutečná čísla. Ale to Mela od zopakování své žádosti o dostatečné informace neodradilo; řekl, že odhalit některé regrese trvá dlouho, což přidává na důležitosti toho dokázat zopakovat staré testy.

Ted Ts'o se zmínil o potřebě mít konkrétní způsob benchmarkování pro každý subsystém. Pak se zeptal, jestli by konkrétní subsystémy byly vůbec schopny se shodnout na rozumné metrice, a upozornil, že tato metrika by neměla běžet moc dlouho (protože věci, co trvají dlouho, nakonec lidi v reálu nebudou spouštět skoro vůbec). Mel nabídl, že pokud by to bylo nutné, pomohl by s přípravou konfiguračních skriptů pro jaderné subsystémy. Odtud se debata přesunula k několika souvisejícím tématům, aniž by se dospělo ke konkrétním rozhodnutím. Tak či tak jsou výkonnostní regrese něčím, co jaderným vývojářům dělá vrásky, takže se k tématu benchmarků jistě brzy vrátí.

Jaderný summit 2012: Distribuce a upstream

Téma „distribucí a upstreamu“ na Jaderném summitu se točilo kolem otázky, kterou formuloval Ted Ts'o: Jak můžene z hlediska upstreamu lépe pomáhat distribucím? Za distribuce na tyto otázky odpovídali dva zástupci: Ben Hutchings za Debian a Dave Jones za Fedoru.

Ben Hutchings požádal o to, aby jaderní vývojáři, když zvažují zařazení nové funkce, neslyšeli na argument, že tato funkce představuje zátěž, ale to je v pořádku, protože půjde vypnout. Poukázal na to, že tento argument je postaven na logickém nesmyslu, neboť až na výjimky tuto volbu všechny distribuce povolí, jelikož ji někteří uživatelé budou potřebovat. Jako příklad Ben uvedl paměťové řídící skupiny (memcg), které ve své první verzi byly výkonnostně náročné.

Druhou věcí pak jsou funkce, které distribuce stále musejí přidávat a nejsou začleněny do upstreamu. Loňským takovým případem by byl Android. V současnosti by to pak byla funkce union mounts. Jelikož je údržba těchto funkcí mimo hlavní řadu jádra pro distribuce náročná, rád by viděl jejich aktivnější začleňování.

Dave Jones se zmínil o třech věcech. První bylo to, že některé popisy pro Kconfig jsou opravdu příšerné. Kvůli tomu pak údržbáři distribucí musejí pročítat kód, aby zjistili, jestli mají funkci zapnout.

Druhou věcí bylo to, že by se hodilo mít seznam regresí už při -rc3 nebo -rc4 v daném vývojovém cyklu. Jde mu o to, že se některé regrese projeví mnohem později. Dave také poznamenal, že ve Fedoře vidí mnoho hlášení z lockdepu, které se v jiných distribucích neukazují. Problémem je v obou případech pochopitelně nedostatek časného testování a nad tímto se Ted Ts'o zamyslel: můžeme uživatelům usnadnit spouštění aktuálního jádra (hlavně jader -rc1 a -rc2) a umožnit jim snadný návrat ke stabilnímu jádru, kdyby něco nefungovalo? Na to se ale v následné diskuzi nenašla jasná odpověď.

Matthew Garrett se vrátil k obecnému tématu Kconfig a navázal na jeden z bodů Bena Hutchingse. Kconfig je pro vývojáře důležitý (aby mohli odlehčit jádro pro rychlé sestavování). Jenže protože distribuce vždy povolí téměř všechny volby (jak bylo popsáno výše), tak se vývojáři musí sami sebe zeptat: Pokud neočekáváte, že některá z voleb bude povolena [v distribucích], tak proč tam pak vůbec je? Následně pak Andrea Arcangeli upozornil na jednu drobnou nepříjemnost – kterou jistě zná většina z těch, co někdy sestavovali jádro. Když spouštíte make oldconfig, tak je velmi snadné se překlepnout při mačkání Enter pro přijetí výchozího nastavení „no“ u většiny voleb; pak si najednou uvědomíte, že jste chtěli odpovědět „yes“. V ten moment už ale není cesty zpět a musíte začít od začátku.

Diskuse k tomuto článku

[Jiří J.]

+1 za ten oldconfig, vedle snadného (in-place) hledání v menuconfigu by se opravdu hodilo nějaké jednoduché ncurses rozhraní pro oldconfig - v současné době pouštím v jednom terminálu oldconfig, ve druhém se divám v menuconfigu na změny, které ona option přidá, ve webovém prohlížeči pak googlím, o co vlastně jde, pokud je Kconfig popisek mizerný.

[Andy]

Andrea Arcangeli upozornil

[Luboš Doležel (Doli)]

To je ale blbý jméno Díky

[Michal Kubeček]

Andrea je běžné italské mužské jméno - viz Wikipedia; přinejmenším Andrea Bocelli je známý docela dost.

[Bedňa]

Andrea je u nás Ondrej, len či náhodou nešlo o priezvisko.

[Michal Kubeček]

Ne, šlo o to, že původně bylo v překladu "upozornila".

[Bedňa]

Aha, to sa ľahko pomýli.

[Luboš Doležel (Doli)]

Pak jsem si na něj také vzpomněl, ale při psaní textu mě nenapadlo, že by to mohla nebýt žena.

[Jiří Svoboda]

Tak to jsem myslel, že jsi větší pamětník.

Když se totiž před lety konečně objevilo stabilní jádro 2.4, tak tam byly nějaké potíže s výkonem VM. Andrea Arcangeli celé VM pak přepsal a Linus ho přijal jako změnu (velkou změnu) do stabilní řady. Bylo z toho tehdy velké haló a Andrea tehdy dával i nějaké rozhovory. Od té doby si každý pamětník musí pamatovat, že je Andrea chlap.

Více zde: http://lwn.net/2001/0927/kernel.php3 (Mám pocit, že jsem to četl v češtině, ale tyhle jaderné noviny jsem zde v češtině nedohledal.)

[Luboš Doležel (Doli)]

Já jsem začal takhle detailně sledovat vývoj jádra vlastně až jakmile jsem začal JN překládat

[VS]

Dobrý den,

jak obvykle výborné čtení, děkuji mnohokrát překladateli a editorovi! A to nejen za tento díl.

A jeden drobounký překlep k opravení (e na a).

Trinity například říká, že čísla o hodnotě druhé mocniny plus nebo mínus jedna jsou často dobrá k vyvolání chyb ve zpracování argumentů určujících „délku“).

Ještě jednou díky za jaderné noviny!

[frr]

A není to spíš mocnina dvou, než druhá mocnina?

[Luboš Doležel (Doli)]

Díky.

[Bedňa]

Sa pripájam, vždy to rád čítam.

V tomto diely ma prekvapil Ben Hutchings, že keď už im kerneláci vyšli v ústrety, prečo si nevyžiadal freeconfig, bez uzavretých driverov a firmwerov. Osobne by som žiadal aj baseconfig (len to najnutnejšie pre chod), embeddedconfig, desktopconfig a serverconfig. Kto niekedy kompiloval jadro, vie koľko hodín trvá vyhádzať nepotrebný balast. Potom diff medzi konfigmi by bola dobrá pomoc, ktoré voľby sú pre aké nasadenie vhodné.