AbcLinuxu:/ Články / Jaderné noviny - 18. 3. 2009

Štítky: ext3, ext4, jádro, kernel, Linux, souborové systémy, SystemTap

Jaderné noviny - 18. 3. 2009

16. 4. 2009 | Jirka Bourek | Jaderné noviny | 3562×

Aktuální verze jádra: 2.6.29-rc8. Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds. Ts'o: Zpožděná alokace a problém souborů o nulové délce. Garrett: ext4, očekávání aplikací a správa napájení. Jádro má nové logo. Pohled na ftrace. Odkud přišlo 2.6.29.

Obsah

Aktuální verze jádra: 2.6.29-rc8
Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds
Ts'o: Zpožděná alokace a problém souborů o nulové délce
Garrett: ext4, očekávání aplikací a správa napájení
Jádro má nové logo
Pohled na ftrace
Odkud přišlo 2.6.29

Aktuální verze jádra: 2.6.29-rc8

link

Současné vývojové jádro 2.6 je stále 2.6.29-rc8 vydané Linusem 12. března. Obsahuje obvyklou sadu oprav a tempo patchů se rozhodně zpomaluje. Ve skutečnosti se zdá, že se stabilizuje do bodu, ve kterém doufám, že se blížíme ke konečnému 2.6.29 a že toto by mohlo být poslední -rc. Uvidíme. Zkrácený changelog je v oznámení, v kompletním changelogu vizte všechny detaily.

V době psaní tohoto článku bylo od vydání 2.6.29-rc8 začleněno téměř 200 sad změn. Většinou jde o opravy, také je zde nové logo maskota, ovladač pro adaptéry Server Engines BladeEngine 2 a ovladač "Dave" pro ethernetové řadiče na deskách Qong FPGA.

Současné stabilní jádro 2.6 je stále 2.6.28.8 vydané 16. března. Ve stejnou dobu byla vydána aktualizace 2.6.27.20. Obě obsahují více než obvykle dlouhý seznam důležitých oprav.

Citáty týdne: Andrew Morton, Patrick McHardy, Linus Torvalds

link

Bylo to přidáno před pěti nebo šesti lety a nikdy jsem nemusel sníst svůj klobouk.

-- Andrew Morton

S velkým zpožděním jsem konečně vydal první kompletní veřejnou verzi svého kódu nftables (včetně uživatelského prostoru), které jsou míněny jako náhrada pro iptables. Jsou napsány od základu a od iptables se v mnoha ohledech liší jak co se vlastností, tak návrhu týče...

-- Patrick McHardy

Tyhle diskuze už mě opravdu přestaly bavit. Viděl jsem téměř nulové kritické myšlení. Pravděpodobně proto, že každý, kdo o tom měl alespoň nějaké pochyby, jednoduše z diskuze zmizel. Takže tady je můj příspěvek: začněte v malém, začněte znovu a začněte přemýšlet i o jiných záležitostech než jsou jenom kontrolní body.

-- Linus Torvalds se snaží restartovat diskuzi o kontrolních bodech

Ts'o: Zpožděná alokace a problém souborů o nulové délce

link

Zde je text od Teda Ts'o o ext4, zpožděné alokaci a robustnosti. Jaká je nejlepší cesta kupředu? Prozatím bych Ubuntu hráčům, jejichž systémy neustále padají a kteří by chtěli používat ext4, doporučil připojovací volbu nodelalloc. Nevyčísloval jsem, jaký bude v tomto režimu postih na výkonnosti, ale měla by být lepší než u ext3 a alespoň se tímto způsobem nebudou muset bát, že se jejich soubory v důsledku zpožděné alokace ztratí. Dlouhodobě by autoři aplikací, kteří mají obavy ze ztráty souborů při nečistém vypnutí, měli opravdu používat fsync.

Garrett: ext4, očekávání aplikací a správa napájení

link

Zde je příspěvek Mattgewa Garretta k debatě o ext4. Nevhodný pro lidi, kterým vadí klení. Milí autoři souborových systémů - vývojáři aplikací rádi zapisují spousty malých souborů, protože to hodně věcí významně zjednodušuje. To je v pořádku, protože čistá výkonnost souborového systému není na seznamu priorit typického vývojáře aplikací vysoko. Odpověď není, 'ehm, všichni byste měli používat sqlite'. Jestliže jediný efektivní způsob, jak používat souborový systém, je použít místo něj databázi, pak to naznačuje, že jste nenapsali souborový systém vhodný pro typického vývojáře aplikací, který si libuje v ukládání věcí do souborů místo do binárních blobů, které končí s úplně odlišnou sadou patologického chování.

Jádro má nové logo

link

Jak všichni ví, do hlavní řady se v takto pozdní fázi vývojového cyklu začleňují pouze důležité opravy. Jednou z oprav, kterou Linus začlenil 13. března, je SVG obrázek "Tuze", maskota konference linux.conf.au 2009 ve vysokém rozlišení. Tuz, jehož nový domov je v Documentation/logo.svg má světu připomínat problémy, kterým čelí populace tasmánských čertů, a že účastníci linux.conf.au podporují snahu zachránit tento druh před vymřením.

Pohled na ftrace

link

Linux má poměrně hodně možností sledování, nejvýznamnější je SystemTap, ale konkrétně toto řešení ještě stále není jednoduše použitelné, částečně přinejmenším pro svou závislost na nástrojích a konfiguraci v uživatelském prostoru. Další možnost, která původně přišla z práce na realtimovém Linuxu, je ftrace. Ftrace je uzavřené řešení, které nepotřebuje žádné nástroje nebo podporu z uživatelského prostoru a které je užitečné pro vysledování problémů - nejenom v jádře, ale i v jeho interakci s uživatelským prostorem.

Jméno ftrace pochází ze "sledovač funkcí" [function tracer], což bylo jeho původním účelem, nicméně nyní může dělat víc než to. Byly přidány různé další sledovače, které se mohou dívat na věci jako přepínání kontextu, jak dlouho jsou zakázaná přerušení, jak dlouho trvá, než se úlohy o vysoké prioritě mohou rozběhnout poté, co byly probuzeny atd. Zrození v realtime stromě je patrné na aktuálně dostupných sledovačích, ale ftrace také obsahuje framework pro pluginy, což umožňuje snadné přidání nových sledovačů.

Na vhodně konfigurovaném jádře - s povoleným CONFIG_FUNCTION_TRACER - se k ftrace přistupuje přes souborový systém debug. Ten je typicky připojen takto:

# mount -t debugfs nodev /debug

To vytvoří podadresář /debug/tracing, který se používá k řízení ftrace a pro získání výstupu tohoto nástroje.

Konkrétní sledovač, který použít, se vybírá zápisem do /debug/tracing/current_tracer, potenciálně po zjištění, které sledovače jsou k dispozici, čtením /debug/tracing/available_tracers. Na současném čistém jádře Fedory vypsání dostupných sledovačů vyústí v:

# cat /debug/tracing/available_tracers
power wakeup irqsoff function sysprof sched_switch initcall nop

Sledování je poté zapnuto či vypnuto zápisem do /debug/tracing/tracing_enabled. Sledovač funkcí by se použil takto:

# echo function >/debug/tracing/current_tracer
# echo 1 >/debug/tracing/tracing_enabled
...další příkazy nebo aktivity, které sledovat...
# echo 0 >/debug/tracing/tracing_enabled

To vytvoří sledování všech volaných jaderných funkcí společně s časovou značkou, která umožní jadernému hackerovi zjistit, co se uvnitř jádra děje.

Výstup z ftrace lze číst z jednoho z mnoha souborů v adresáři tracing:

trace - obsahuje výstup sledování v čitelné podobě
latency_trace - obsahuje výstup stejného sledování, ale organizován je tak, že lze diagnostikovat problémy s latencí, také v čitelné podobě
trace_pipe - obsahuje stejný výstup jako trace, ale je míněn k přesměrování do roury příkazu. Na rozdíl od předchozích dvou čtení z toho souboru výstup spotřebovává.

Kruhový buffer používaný ftrace má pevnou velikost (určenou podle souboru buffer_size_kb), takže záznamy v trace a latency_trace se přepisují.

Zde jsou příklady výstupu ze sledování funkcí. Hlavička pomáhá dekódovat různé pole ve sledování. Takto vypadá výstup z trace (značně pozměněný za účelem stručnosti):

# tracer: function
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
            bash-3330  [000]   147.799029: sys_open <-syscall_call
            bash-3330  [000]   147.799030: do_sys_open <-sys_open
            bash-3330  [000]   147.799030: getname <-do_sys_open
            bash-3330  [000]   147.799031: kmem_cache_alloc <-getname

Toto je výstup latency_trace (podobně upravený):

# tracer: function
#
function latency trace v1.1.5 on 2.6.29-0.215.rc7.fc11.i586
--------------------------------------------------------------------
 latency: 0 us, #120119/5425477, CPU#0 | (M:desktop VP:0, KP:0, SP:0 HP:0 #P:2)
    -----------------
    | task: -0 (uid:0 nice:0 policy:0 rt_prio:0)
    -----------------

#                  _------=> CPU#            
#                 / _-----=> irqs-off        
#                | / _----=> need-resched    
#                || / _---=> hardirq/softirq 
#                ||| / _--=> preempt-depth   
#                |||| /                      
#                |||||     delay             
#  cmd     pid   ||||| time  |   caller      
#     \   /      |||||   \   |   /           
    bash-3330    0.... 3531221us : sys_open (syscall_call)
    bash-3330    0.... 3531222us : do_sys_open (sys_open)
    bash-3330    0.... 3531222us : getname (do_sys_open)
    bash-3330    0.... 3531223us : kmem_cache_alloc (getname)

Každý řádek v obou výstupních formátech ukazuje jedno volání funkce s jednou úrovní zpětného sledování [backtrace], společně se jménem procesu, ID procesu a informací o tom, na kterém CPU volání proběhlo. Výstup latency_trace také poskytuje informaci o tom, jestli byla zakázána přerušení, jestli bylo vyvoláno přeplánování, jestli funkce běžela v kontextu přerušení a jestli byla zakázaná preempce. Časová značka výstupu latency_trace je relativní vůči začátku sledování, udána je v mikrosekundách; mezera mezi časem a dvojtečkou je pole, které může být nastaveno na '!' nebo '+', aby se přitáhla pozornost na obzvláště dlouhá zpoždění (v tomto příkladu je toto pole vždy prázdné). Hlavička bohužel trochu mate v tom, kam ukazují pole "delay" (zpoždění) a "caller" (volající).

Sysctl kernel.ftrace_enabled určuje, jestli je vstup do funkce zaznamenán jako součást sledování. Zapnout ho lze jedním z těchto dvou příkazů:

# sysctl kernel.ftrace_enabled=1 
nebo 
# echo 1 >/proc/sys/kernel/ftrace_enabled

Bez toho je mnoho sledovačů v podstatě k ničemu.

Půl tuctu různých sledovačů je popsáno v rozsáhlém Documentation/ftrace.txt, který je uložen ve stromě zdrojových kódů jádra. Kromě sledovače funkcí je zde sledovač sched_switch, který sleduje a hlásí přepínání kontextu v jádře a ukazuje přitom probuzení procesů společně s tím, kdy jsou naplánovány. Každý záznam ve sledování obsahuje značku společně s prioritami a stavy dotčených procesů.

Sledovač nop není sledovač, ale lze ho využít k vyčištění kteréhokoliv sledovače, který je zrovna aktivní. V hlavní řadě je sedm dalších sledovačů, které se ještě nedostaly do dokumentace. Kromě nich je ještě více sledovačů, které míří do jádra 2.6.30.

Jsou zde čtyři, které hledají maximální čas strávený v daném stavu a zaznamenávají toto maximum (v trace_max_latency) společně se sledováním funkcí, které byly v tomto stavu zavolány. irqsoff hledá nejdelší čas strávený se zakázanými přerušeními, preemptoff nejdelší čas strávený s vypnutou preempcí. Kombinace těchto dvou dává sledovač preemptirqsoff. Poslední sledovač wakeup zaznamenává nejdelší latenci mezi okamžikem, kdy je proces s nejvyšší prioritou probuzen a kdy je naplánován.

Každý z nich pomáhá omezením množství sledovacích dat, kterými se jaderný hacker musí probrat. Pro jádra, která jsou konfigurována s CONFIG_DYNAMIC_FTRACE je zde další způsob, jak tato data filtrovat. Dynamické ftrace umožňuje uživateli vybrat, které jaderné funkce jsou do sledování buď zahrnuty, nebo z něj vyjmuty. Soubor available_filter_functions vypisuje seznam funkcí, které mohou být filtrovány, přičemž zapsání jména funkce do set_ftrace_filter či set_ftrace_nofilter tyto funkce zahrne nebo vynechá. Seznam lze doplňovat pomocí standardního operátoru přesměrování >> v shellu. Navíc je zde podpora pro divoké znaky [wildcards], takže:

echo 'hrtimer_*' >/debug/tracing/set_ftrace_filter

bude sledovací informace sbírat jenom pro funkce časovače s vysokým rozlišením.

Další sledovače dostupné v jádře hlavní řady (tj. v tom, ze kterého bude 2.6.29), zahrnují:

power - sleduje přechody mezi napájecími stavy CPU
function_graph - podobný sledovači funkcí, ale sleduje jak vstup do funkce, tak její opuštění, což umožňuje vygenerování grafu volání.
sysprof - periodicky (určeno sysprof_sample_period) generuje výpis zásobníku pro běžící proces nebo jaderné vlákno
initcall - sleduje vstup a opuštění inicializační funkce během bootu systému
branch - sleduje předpovídání skoků a jejich vykonávání
hw-branch-tracer - ke sledování vykonávání skoků používá vlastnost Branch Target Stack (BTS) procesorů x86
mmiotrace - sleduje paměťově mapované I/O

Vytváření čitelného výstupu přímo v jádře nedávno vedlo k tvrdým otázkám od Andrewa Mortona: Proč pořád pokračujeme ve vkládání těchto hezkých vypisovačů a hezkých parserů do jádra? Nebo jinak, jak těžké je pro uživatelský prostor přečíst textový soubor, provést několik základních náhrad a zase ho vypsat? Jiní ale argumentují, že jednoduchost toho dostat přímo od jádra čitelný výpis je přesně to, díky čemu je ftrace tak užitečné.

Andrew argumentuje, že pevný formát je obtížnější zpracovávat [parse] skripty a výstup je pouze anglický. Tvrdí, že nějaký druh API by věci zjednodušilo. Poukázal na výstup latency_trace jako příklad a řekl:

[...] a teď je třeba se zamyslet nad tím, jak by toto rozhraní bývalo bylo navrženo, kdybychom se rozhodli k němu přistupovat něčím chytřejším, než je 'cat'.

Vždyť se na to podívejte. Všechno to zarovnávání sloupců mezerami, zbytečné popisování "us", ta podivná záležitost se symbol(symbol) atd. Navíc by to mělo být více sebepopisující. Teď parser buď musí předpokládat, že druhý znak v "0d..1" je "irqs-off", nebo se musí naučit interpretovat ascii art.

Místo nutnosti mít nějaký nástroj v uživatelském prostoru, který by interpretoval výstup ftrace, může jaderný hacker rychle dostat to, co potřebuje, od samotného jádra. Jak upozornil Ingo Molnár, na cílovém stroji nemusí být prostředí pro překlad, takže přímý výstup ze sledování je užitečný: Soběstačné osazení jádra sledovacími nástroji je klíčový koncept pro použitelnost. Navíc řekl, že výstup je navržen k tomu, aby byl skriptovatelný, ale pokud to není dostatečné, jsou možnosti, jak vygenerovat čistý výstup. Celkově považuje hezké vypisování jádrem za potřebnou vlastnost:

IMO by diskuze o hezkých výpisech v jádře neměla být náboženská, ale technická. Hezké vypisování je nástroj a jako nástroj ho občas lze využít k hloupým účelům a občas k užitečným účelům. Zdá se, že tvrdíš, že dělat to v jádře je vždycky hloupé - a s tím silně nesouhlasím a považuji to za krajní názor - z důvodů naznačených výše.

Volby, na které se Ingo odkazuje, jsou přístupné v souboru trace_options, který vypisuje současné nastavení, když je přečten, změna nastavení je možná zápisem. Formát výstupu řídí volby raw, hex a bin (společně s nějakými dalšími, které rozhodují o tom, která pole jsou vypisována). Tyto volby mohou vygenerovat výstup ve formátu, který může být použitelnější pro nástroje. Možnost získat data ze sledování bez jakéhokoliv nástroje je, přinejmenším někým, považována za velmi důležitou součást ftrace.

Existuje mnohem více voleb a vlastností, které zde nejsou pokryty. Výše zmíněný dokument ftrace.txt je dobrý počáteční bod pro ty, které zajímá více detailů.

Kromě sledovačů, které jsou v současnosti v hlavní řadě, je jich další hrstka, která se připravuje do 2.6.30. To zahrnuje nový sledovač událostí, který umožňuje sledování událostí plánování, zamykání a obsluhy přerušení. Stejně tak je zahrnuto nepřetržité sbírání statistik pro pracovní fronty a predikci skoků.

Ftrace je užitečný nástroj, který může poskytnout skvělé diagnostické informace z běžícího jádra. Není to všeobecný nástroj, stejně tak není vhodný pro lidi, kteří nemají povědomost o vnitřnostech jádra, ale rozhodně má svá využití. Kolem ftrace je v současnosti hodně aktivity, na linux-kernel poletuje mnoho patchů a vylepšení. I když možná přímo neomezuje závist z Dtrace, je to nástroj, který dnes používá mnoho vývojářů.

Odkud přišlo 2.6.29

link

Tady v redakci Jaderných novin jsme velcí tradicionalisté, a proto, jak se vývojový cyklus 2.6.29 blíží ke svému konci, nás tradice nutí podívat se na to, odkud ten kód přišel.

K 17. březnu bylo do jádra 2.6.29 začleněno 11 610 neslučovacích sad změn. Tyto patche přidaly ohromujících 1 228 000 řádků kódu a dokumentace, odstranily jich 401 000; jádro 2.6.29 bude mít o 827 000 řádků víc než jeho předchůdce. V tomto cyklu se zúčastnilo nějakých 1166 vývojářů. Autor tohoto článku se s pocitem, že je to možná rekord, rozhodl podívat se na předchozí jádra:

Verze	Vývojářů
2.6.22	885
2.6.23	854
2.6.24	950
2.6.25	1124
2.6.26	1027
2.6.27	1022
2.6.28	1078
2.6.29	1166

Zdá se, že je zde jasný trend: jaderná komunita vývojářů se během posledních pár let výrazně zvětšila. Počet zaměstnavatelů, kteří za těmito vývojáři stojí (175), se zvětšil o málo, ale kvůli nejistotě platnosti spojení zaměstnavatele s vývojářem je vhodné toto číslo nebrat příliš vážně. Stačí říct, že je tu pár firem, které podporují vývoj jádra.

Zde jsou statistiky jednotlivých vývojářů:

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

Podle sad změn
Chris Mason	671	5,8 %
Takashi Iwai	173	1,5 %
Jaswinder Singh Rajput	158	1,4 %
Stephen Hemminger	154	1,3 %
Mike Frysinger	150	1,3 %
Christoph Hellwig	143	1,2 %
Ben Dooks	142	1,2 %
Alexey Dobriyan	138	1,2 %
Ingo Molnár	133	1,1 %
Rusty Russell	127	1,1 %
Steven Rostedt	110	0,9 %
Mauro Carvalho Chehab	109	0,9 %
Mark Brown	108	0,9 %
Sam Ravnborg	108	0,9 %
David S. Miller	107	0,9 %
Greg Kroah-Hartman	105	0,9 %
Harvey Harrison	101	0,9 %
David Howells	100	0,9 %
Russell King	93	0,8 %
Paul Mundt	87	0,7 %

Podle změněných řádků
Greg Kroah-Hartman	280883	20,8 %
Luis R. Rodriguez	71604	5,3 %
Chris Mason	69935	5,2 %
Daniel Krueger	56534	4,2 %
David Kiliani	41371	3,1 %
David Daney	18767	1,4 %
Solomon Peachy	17386	1,3 %
Robert Love	15262	1,1 %
Sujith	14703	1,1 %
Inaky Perez-Gonzalez	14388	1,1 %
David S. Miller	13422	1,0 %
Jesse Barnes	13036	1,0 %
Christoph Hellwig	12548	0,9 %
Michael Hennerich	12334	0,9 %
Subbu Seetharaman	12285	0,9 %
Jaswinder Singh Rajput	11651	0,9 %
Rusty Russell	10878	0,8 %
Ben Dooks	10809	0,8 %
David Schleef	10325	0,8 %
Mark Brown	9945	0,7 %

Chris Mason se na vrchol v kategorii "podle sad změn" dostal díky začlenění Btrfs. To je jistě významný kus kódu, ale počet sad změn je zde tak vysoký, protože byla začleněna kompletní vývojová historie Btrfs. Vidíme zde tedy o něco více než tři měsíce práce. Takashi Iwai udělal spoustu práce v subsystému ALSA, konkrétně na ovladači Intel HDA. Jaswinder Singh Rajput přispěl mnoha pročišťovacími patchi. Práce Stephen Hemmingera sestávala hlavně ze změny API síťových ovladačů a poté opravy dlouhého seznamu rozbitých ovladačů. A Michael Frysinger přispěl mnoha změnami v architektuře Blackfin.

Pokud se podíváme na řazení podle počtu změněných řádků, výsledný obraz se trochu liší. Jako v 2.6.28 Greg Kroah-Hartman nacpal do stromu -staging velké množství svinstva (jeho výraz); tento kód neobsahuje v gitovém repozitáři původní informace o autorovi (i když ocenění v kódu samozřejmě zůstávají). Luis Rodriguez udělal spoustu práce na bezdrátových ovladačích Atheros a subsystému cfg80211; velká část jeho práce je spojena s podporou regulace bezdrátových zařízení. Daniel Krueger svého místa v žebříčku dosáhl zasláním jediného patche: síťového stacku Systec Electronic openPOWERLINK. David Kiliani je další jednopatchový zázrak; jeho je ovladač pro karty Meilhaus ME-IDS pro sběr dat. Danielovy a Davidovy patche přešly do stromu -staging, přes -staging se tedy do hlavní řady dostala práce tří z pěti největších přispěvatelů kódu.

Statistiky zaměstnavatelů spojených s vývojáři vypadají takto:

Nejaktivnější zaměstnavatelé v 2.6.29

Podle sad změn
(žádný)	1612	13,9 %
(neznámý)	1378	11,9 %
Red Hat	1229	10,6 %
Oracle	992	8,5 %
IBM	749	6,5 %
Intel	686	5,9 %
Novell	632	5,4 %
(konzultant)	370	3,2 %
Analog Devices	282	2,4 %
Fujitsu	212	1,8 %
(školství)	204	1,8 %
Renesas Technology	165	1,4 %
Nokia	163	1,4 %
Vyatta	154	1,3 %
Parallels	149	1,3 %
Simtec	138	1,2 %
Atheros Communications	131	1,1 %
AMD	130	1,1 %
Wolfson Microelectronics	104	0,9 %
SGI	100	0,9 %

Podle změněných řádků
Novell	306183	22,7 %
(neznámý)	197224	14,6 %
Atheros Communications	96202	7,1 %
Oracle	93846	7,0 %
(žádný)	92811	6,9 %
Red Hat	77087	5,7 %
Intel	62265	4,6 %
SYS TEC electronic GmbH	56534	4,2 %
Analog Devices	44659	3,3 %
IBM	40560	3,0 %
(konzultant)	28983	2,1 %
Cavium Networks	18767	1,4 %
Renesas Technology	16946	1,3 %
Nokia	11951	0,9 %
Simtec	10886	0,8 %
Broadcom	10314	0,8 %
Wolfson Microelectronics	10147	0,8 %
Freescale	8520	0,6 %
Chelsio	7738	0,6 %
QLogic	7322	0,5 %

Čísla u zaměstnavatelů se mezi jednotlivými verzemi příliš nemění; většinou se objevují stejné společnosti. Nově se na seznam dostaly Vyatta (podporuje práci Stephena Hemmingera) a některé firmy (Simtec, SYS TEC, Cavium Networks), které dodaly podporu pro své vlastní produkty.

Počet patchů se značkou Revidováno-kým zůstává relativně malý - méně než 5 % ze všech. Nejvíce ocenění revidovatelé jsou tentokrát:

Vývojáři s největším počtem revizí
James Morris	64	20,2 %
Dave Chinner	51	16,1 %
Christoph Hellwig	39	12,3 %
Andrew Morton	14	4,4 %
Eric Sandeen	12	3,8 %
Daisuke Nishimura	11	3,5 %
KOSAKI Motohiro	10	3,2 %
Matthew Wilcox	8	2,5 %
WANG Cong	7	2,2 %
Zhu, Yi	5	1,6 %
KAMEZAWA Hiroyuki	5	1,6 %
Eric Anholt	4	1,3 %
Pekka Enberg	4	1,3 %
Tomas Winkler	4	1,3 %
Paul Menage	4	1,3 %
Mike Christie	4	1,3 %
Grant Grundler	4	1,3 %

Tato čísla jsou velmi ovlivněna tím, jak je hlášeno revidování; rozhodně se reviduje víc, než je zde vidět. Totéž platí pro ocenění za hlášení chyb a testování. Pro 2.6.29 jsou tato čísla takováto:

Nejvíce ocenění ohlašovatelé a testeři v 2.6.29

Ocenění za `ohlášeno-kým`
Randy Dunlap	13	3,8 %
Ingo Molnar	7	2,0 %
Li Zefan	6	1,7 %
Alexander Beregalov	5	1,5 %
Stephen Rothwell	5	1,5 %
Stefan Richter	4	1,2 %
Johannes Berg	4	1,2 %
Eric Sesterhenn	4	1,2 %
Kamalesh Babulal	4	1,2 %
Larry Finger	3	0,9 %
Linus Torvalds	3	0,9 %
Andrew Morton	3	0,9 %
Guennadi Liakhovetski	3	0,9 %
Huang Ying	3	0,9 %
Daisuke Nishimura	3	0,9 %
Meelis Roos	3	0,9 %
Geert Uytterhoeven	3	0,9 %

Ocenění za `testováno-kým:`
Hin-Tak Leung	14	5,2 %
Mike Frysinger	7	2,6 %
Larry Finger	7	2,6 %
Ingo Molnar	6	2,2 %
Herton Ronaldo Krzesinski	6	2,2 %
Li Zefan	5	1,9 %
Daisuke Nishimura	4	1,5 %
KAMEZAWA Hiroyuki	4	1,5 %
Andrew Patterson	4	1,5 %
Meelis Roos	4	1,5 %
KOSAKI Motohiro	3	1,1 %
Stephen Gildea	3	1,1 %
Robert Jarzmik	3	1,1 %
Serge Hallyn	3	1,1 %
Eric Sesterhenn	3	1,1 %

Ve shrnutí byl vývojový cyklus 2.6.29 jedním z nejaktivnějších v historii, do jádra si našlo cestu ohromné množství kódu a padl rekord v počtu spolupracujících vývojářů. Komunita vývojářů by si zaslouženě mohla dát po takové práci přestávku, ale vývoj jádra, zdá se, nikdy nepřestává. V současnosti již spousta kódu čeká na otevření začleňovacího okna 2.6.30, ve kterém celý cyklus začne nanovo.

(Jako vždycky díky Gregu Kroah-Hartmanovi za pomoc při sestavování těchto statistik.)