Jaderné noviny – 10. 2. 2010

3. 3. 2010 | Jirka Bourek | Jaderné noviny | 3364×

Aktuální verze jádra: 2.6.33-rc7. Citát týdne: Al Viro. Kdo napsal 2.6.33 (statistiky přispěvatelů do linuxového jádra, kdo toho nejvíce naprogramoval a kdo ty lidi platil). Podpora skriptování v perf.

Obsah

• Aktuální verze jádra: 2.6.33-rc7
• Citát týdne: Al Viro
• Kdo napsal 2.6.33
• Podpora skriptování v perf

Aktuální verze jádra: 2.6.33-rc7

Současné vývojové jádro je 2.6.33-rc7 vydané 6. února. Musím přiznat, že bych si přál, aby byl seznam regresí touto dobou kratší… Ale rozhodně jsme několik věcí opravili a je to už týden, takže tady je -rc7. Přál bych si, abych mohl říct, že je to poslední -rc, ale o tom silně pochybuji a téměř určitě bude přinejmenším o jedno víc. Detaily vizte v kompletním changelogu.

Stabilní aktualizace: Jádro 2.6.32.8 bylo vydáno 9. února. Omlouvám se za zpoždění při vydání, ale lidé nahlásili několik pádů spojených s tím, že byl bezpečnostní problém opravdu opraven a správně backportován, navíc jsem cestoval na a z FOSDEM, což všechno zabralo nějaký čas. Nejaktuálnější stabilní aktualizace 2.6.27 zůstává 2.6.27.45.

Citát týdne: Al Viro

Abych pravdu řekl, jsem asi takhle -><- blízko tomu napsat neotisknutelný výlev o háčcích [hooks] obecně, o s nimi spojeném stylu vývoje a o výsledných problémech. A přitom jmenovat a ukazovat spoustu příkladů.

LSM je v podstatě odpadkový koš a v podstatě všechno ošklivé končí v něm. To je v pohodě, pokud se někdo nestará o to, jestli jeho kód dává smysl, a jenom ho chce schovat před nepřátelskýma očima.

-- Al Viro

Kdo napsal 2.6.33

Jonathan Corbet, 9. února 2010

Vydání předverze 2.6.33-rc7 naznačuje, že se tento vývojový cyklus blíží ke konci, i když si Linus myslí, že bude potřeba -rc8. Jako tradičně se Jaderné noviny dívají na několik statistik spojených s tímto cyklem a s tím, odkud tento kód přišel.

V době psaní tohoto článku si svou cestu do 2.6.33 našlo 10 500 neslučovacích sad změn – poměrně standardní číslo. Tyto změny přidaly téměř 900 000 řádek kódu a smazaly téměř 520 000 jiných; výsledkem je, že jádro tentokrát narostlo o pouhých 380 000 řádek kódu. Podle aktuálního seznamu regresí bylo v 2.6.33 nahlášeno 97 regresí, z nichž zůstává 20 nevyřešeno.

Do kódu 2.6.33 přispělo nějakých 1 152 vývojářů. Nejaktivnější z nich byli:

Nejaktivnější vývojáři 2.6.33

Podle sad změn Ben Hutchings 145 1,4 % Frederic Weisbecker 145 1,4 % Arnaldo Carvalho de Melo 138 1,3 % Luis R. Rodriguez 130 1,2 % Masami Hiramatsu 128 1,2 % Bartlomiej Zolnierkiewicz 124 1,2 % Eric Dumazet 108 1,0 % Alan Cox 105 1,0 % Manu Abraham 102 1,0 % Thomas Gleixner 101 1,0 % Eric W. Biederman 97 0,9 % Roel Kluin 91 0,9 % Alexander Duyck 88 0,8 % Paul Mundt 87 0,8 % Johannes Berg 80 0,8 % Wey-Yi Guy 77 0,7 % Alex Deucher 76 0,7 % Jean Delvare 73 0,7 % Al Viro 72 0,7 %

Podle změněných řádek Bartlomiej Zolnierkiewicz 206468 18,1 % Henk de Groot 50355 4,4 % Jerry Chuang 49627 4,3 % Ben Skeggs 37555 3,3 % Philipp Reisner 23182 2,0 % Eilon Greenstein 23123 2,0 % Tomi Valkeinen 22508 2,0 % Mike Frysinger 13116 1,1 % Ben Hutchings 12680 1,1 % Jakob Bornecrantz 11613 1,0 % Wu Zhangjin 11325 1,0 % Greg Kroah-Hartman 10468 0,9 % Rajendra Nayak 9978 0,9 % Manu Abraham 9625 0,8 % jack wang 9171 0,8 % Masami Hiramatsu 8973 0,8 % Alan Cox 7672 0,7 % David VomLehn 7331 0,6 % Arnaldo Carvalho de Melo 7217 0,6 %

I když se na čelních příčkách objevují některá ze stálých jmen, jsou zde i nějací nově příchozí. Ben Hutchings odvedl spoustu práce na síťových ovladačích včetně přidání ovladače SolarFlare SFC9000 (který má několik spoluautorů). Frederic Weisbecker byl aktivní v několika oblastech, přidal kód hardwarových bodů přerušení [breakpoints], pracoval na odstranění velkého jaderného zámku [Big Kernel Lock] ze souborového systému reiserfs a také na sledování a nástroji perf. Práce Arnalda Carvalho de Melo se téměř kompletně týkala subsystému událostí výkonnosti a obzvláště nástroje perf. Luis Rodriguez nadále pracuje na subsystému bezdrátových ovladačů, nejvíce na ovladači Atheros, a největší příspěvek Masamiho Hiramatsu je práce na dynamickém sledování [dynamic probing].

Ve sloupci „podle změněných řádků“ Bartlomiej Zolnierkiewicz dál opravuje některé ovladače bezdrátových zařízení ve stromě staging, přičemž maže spoustu kódu; také stále pracuje na IDE. Henk de Groot přidal ovladač Agere pro čipové sady HERMES II, Jerry Chuang přidal ovladač pro Realtek rtl8192u a Ben Skeggs většinu ovladače Nouveau.

Autor článku byl schopen identifikovat u příspěvků do 2.6.33 182 zaměstnavatelů. Nejaktivnější z nich byli:

Nejaktivnější zaměstnavatelé v 2.6.33

Podle sad změn (žádný) 1535 14,6 % Red Hat 1223 11,6 % Intel 1011 9,6 % (neznámý) 868 8,3 % IBM 500 4,8 % Novell 390 3,7 % Nokia 319 3,0 % (konzultant) 316 3,0 % Fujitsu 204 1,9 % Texas Instruments 199 1,9 % Atheros Communications 169 1,6 % (školství) 166 1,6 % AMD 165 1,6 % Oracle 136 1,3 % Analog Devices 130 1,2 % Renesas Technology 126 1,2 % Pengutronix 125 1,2 % HP 124 1,2 % Solarflare Communications 123 1,2 %

Podle změněných řádků (žádný) 304895 26,7 % (neznámý) 109716 9,6 % Red Hat 92991 8,1 % Broadcom 54272 4,8 % Realtek 49951 4,4 % Intel 46302 4,1 % Nokia 37505 3,3 % Novell 27235 2,4 % IBM 26783 2,3 % (konzultant) 25845 2,3 % Texas Instruments 24232 2,1 % LINBIT 23247 2,0 % Analog Devices 19677 1,7 % VMWare 16045 1,4 % Samsung 15707 1,4 % Solarflare Communications 15054 1,3 % JiangSu Lemote Corp. 11439 1,0 % AMD 9218 0,8 % Universal Scientific Industrial Co. 9194 0,8 %

Jako obvykle si Red Hat drží pozici na začátku seznamu, ale ostatní ho dohánějí; možná se dočkáme dne, kdy Red Hat bude jenom jedním z několika velkých přispěvatelů. Některé čtenáře možná překvapí, že na čelních příčkách vidí Broadcom, vzhledem k tomu, že tato firma nemá jako přispěvatel nejlepší pověst. Pravda je taková, že Broadcom zaměstnává několik vývojářů přispívajících do různých ovladačů v subsystémech síťování a SCSI; problémy jsou jenom v říši bezdrátových zařízení.

Jenom tak ze srandy autor opsal „procenta sad změn“ posledních deseti vydání do tabulky a dostal tento graf:

Toto rozdělení je za poslední tři roky překvapivě stabilní. Nejzjevnější identifikovatelné trendy jsou pravděpodobně plynulé nárůsty hodnot u Intelu a Nokie.

Vývojový proces dál pokračuje plynule. Když zanedbáme občasné stížnosti na to, že se některé firmy vývojového procesu neúčastní naplno, je celkový obraz takový, že stovky firem spolupracují na vytváření linuxového jádra, i když jinde spolu nemilosrdně soupeří. Významné procento kódu, který pochází od vývojářů pracujících ve svém volném čase, nicméně ukazuje, že Linux není jenom firemní záležitost. Vystavěli jsme vývojovou komunitu, která je schopna zabudovat zájmy a práci ohromujícího množství lidí do jediného jádra.

Jako vždycky díky Gregu Kroah-Hartmanovi, který věnoval spoustu práce tomu, aby v tabulkách výše omezil počet procent u záznamů (neznámý).

Podpora skriptování v perf

Jake Edge, 10. únor 2010

Nástroj perf pro analýzu chování systému rychle získává další funkce. Od začlenění do hlavní řady v 2.6.31, kde sloužil jako prostředek pro přístup k různým čítačům výkonnosti [performace counters] v CPU, svůj záběr rozšířil. Přibližně ve stejné době se do jádra dostala podpora pro obsluhu jaderných událostí jako událostí čítačů výkonnosti. V nedávné době Tom Zanussi přidal podporu pro používání skriptů v perlu a pythonu s nástrojem perf, takže ještě zjednodušil sofistikované zpracování událostí výkonnosti [perf events].

Podpora perlu již v hlavní řadě je, ale Tom nedávno přidal skriptovací engine pro python. Interpretery pro perl i python lze zabudovat do spustitelného souboru perf, což umožňuje zpracovávat čistá sledovaná data v kterémkoliv z těchto dvou jazyků.

Skriptování v perlu lze použít od verze 2.6.33-rc, ale podpora pythonu je k dispozici pouze po aplikování Tomových patchů na strom tip. Překlad perfu v adresáři tools/perf, což vyžaduje vývojové verze různých knihoven a nástrojů (glibc, elfutils, libdwarf, perl, python, atd.), poté dává přístup k nové funkcionalitě.

S perfem jsou dodávány různé příklady – skripty, které může vypsat perf sám:

# perf trace -l
List of available trace scripts:
  syscall-counts [comm]                system-wide syscall counts
  syscall-counts-by-pid [comm]         system-wide syscall counts, by pid
  failed-syscalls-by-pid [comm]        system-wide failed syscalls, by pid
  workqueue-stats                      workqueue stats (ins/exe/create/destroy)
  check-perf-trace                     useless but exhaustive test script
  failed-syscalls [comm]               system-wide failed syscalls
  wakeup-latency                       system-wide min/max/avg wakeup latency
  rw-by-file <comm>                    r/w activity for a program, by file
  rw-by-pid                            system-wide r/w activity

To je seznam směsi skriptů v perlu a pythonu, které žijí v adresářích tools/perf/scripts/{perl,python} a po make install jsou nainstalovány do správného místa (ve výchozím nastavení /root/libexec).

Skripty samy o sobě jsou z větší části generovány příkazem perf trace. Tomova dokumentace pro perf-trace-perl a perf-trace-python popisuje proces použití perf trace k vytvoření kostry skriptu, který lze poté editovat a přidat do něj potřebnou funkcionalitu. Přidání dvou podpůrných skriptů v shellu (pro záznam a hlášení) do správného adresáře přidá nové skripty do seznamu, který vypisuje příkaz perf trace popsaný výše.

Nainstalované skripty lze poté využít následovně:

# perf trace record failed-syscalls
^C[ perf record: Woken up 11 times to write data ]
[ perf record: Captured and wrote 1.939 MB perf.data (~84709 samples) ]

Tím jsou zachycena data z nástroje perf do souboru pojmenovaného perf.data, který následně lze zpracovat takto:

# perf trace report failed-syscalls
perf trace started with Perl script \
    /root/libexec/perf-core/scripts/perl/failed-syscalls.pl


failed syscalls, by comm:

comm                    # errors
--------------------  ----------
firefox                     1721
claws-mail                   149
konsole                       99
X                             77
emacs                         56
[…]

failed syscalls, by syscall:

syscall                           # errors
------------------------------  ----------
sys_read                              2042
sys_futex                              130
sys_mmap_pgoff                          71
sys_access                              33
sys_stat64                               5
sys_inotify_add_watch                    4
[…]

# perf trace report failed-syscalls-by-pid
perf trace started with Python script \
    /root/libexec/perf-core/scripts/python/failed-syscalls-by-pid


syscall errors:

comm [pid]                           count
------------------------------  ----------

firefox [10144]
  syscall: sys_read
    err = -11                         1589
  syscall: sys_inotify_add_watch
    err = -2                             4

firefox [10147]
  syscall: sys_futex       
    err = -110                           7
[…]

Tento jednoduchý příklad ukazuje použití skriptu failed-syscalls k sesbírání dat a jejich následnému zpracování odpovídajícím skriptem v perlu stejně jako kompatibilním skriptem v pythonu (failed-syscall-by-pid), který data dělí trochu jinak. První hlášení ukazuje počet systémových volání během několika vteřin, kdy se sledovalo. Ukazuje počet chyb podle procesu a podle systémového volání.

Druhé hlášení kombinuje obojí a ukazuje každý proces společně s tím, jaká systémová volání ve spojení s ním selhala a kolikrát. Také existují odpovídající skripty, které počítají všechna systémová volání, ne jenom ta, která selhala, a hlásí je podobně. Jiné dodávané skripty se zabývají latencí probouzení, aktivitou čtení/zápisů do souboru a statistikami pracovních front.

Tyto možnosti skriptování zjednoduší jaderným hackerům – nebo možná i těm, kteří jimi nejsou – přístup k funkcionalitě nástroje perf. Stav sledování a osazení jádra se v posledních vývojových cyklech rychle zlepšuje a nezdá se, že by se tempo mělo v brzké době zpomalit.

       

Komentáře

[Jan Grmela]

Návrh: Co změnit "práce na dynamickém sledování [dynamic probing]" span "práce na dynamickém sledování" s titulkem "dynamic probing"?

[vasek125]

2.6.33 je nejhorší jádro jaké jsem kdy používal. Sice něm výjimečně funguje wifi s iwlagn, ale systém nabíhá cca 25 minut, grafika se seká, přenosová rychlost na disku klesla ze 120 na 30MB/s, po uspání se už neprobudí(waiting for wifi). Už ani nemám sílo dávat bugreport, jenom doufám, že tohle jádro nebude v dalším ubuntu. Zajímalo by mě kolik u vás má problémy s iwlagn jako já(částé odpojování, přerušování spojení...). Wifi fungovala dobře jen na 2.6.28, do té doby skoro ne, od té doby se to zas zhoršuje, v každém novém jádře nefunguje něco.

[Slavko]

Ja mám síce zatiaľ len 2.6.32 a bez WiFi, ale moje pocity sú podobné, len začali už po 2.6.26 - tel. karta je použiteľná len s veľkou dávkou fantázie a moje disky, proste hrôza, hoci k 30 MB/s som sa zatiaľ nedostal

[Marián Kyral]

2.6.33 je nejhorší jádro jaké jsem kdy používal. Sice něm výjimečně funguje wifi s iwlagn, ale systém nabíhá cca 25 minut, grafika se seká, přenosová rychlost na disku klesla ze 120 na 30MB/s, po uspání se už neprobudí(waiting for wifi). Už ani nemám sílo dávat bugreport, jenom doufám, že tohle jádro nebude v dalším ubuntu. Zajímalo by mě kolik u vás má problémy s iwlagn jako já(částé odpojování, přerušování spojení...). Wifi fungovala dobře jen na 2.6.28, do té doby skoro ne, od té doby se to zas zhoršuje, v každém novém jádře nefunguje něco.

Fakt 25 minut? A co ten systém dělá? Já se startem nemám na Gentoo nejmenší problémy (2.6.33-gentoo-ck1, Dell E6500). Iwlagn a uspávání taktéž bez problémů. S wifi jsem měl problémy na jiném NB, tam mám iw3945 nebo tak nějak. Kernel 2.6.31 v pohodě, 2.6.32 - odpojování. Tak jsem se vrátil zpět k .31. O víkendu se snad dostanu k tomu otestovat .33.

[Jan Grmela]

Sice nechápu jak to souvisí s mým původním postem ale na 2.6.32.něco mi funguje Intel 5100 naprosto v pohodě včetně WPA Enterprise. Asi mám štěstí.