Jaderné noviny – 8. 3. 2012: Statistiky Linuxu 3.3

19. 3. 2012 | Luboš Doležel

Články - Jaderné noviny – 8. 3. 2012: Statistiky Linuxu 3.3  

Aktuální verze jádra: 3.3-rc6. Citáty týdne: Andrew Morton, Rusty Russel. Dva způsoby, jak počítat jadernou paměť. Statistiky vývojového cyklu verze 3.3.

Obsah

• Aktuální verze jádra: 3.3-rc6
• Citáty týdne: Andrew Morton, Rusty Russel
• Dva způsoby, jak počítat jadernou paměť
• Statistiky vývojového cyklu verze 3.3

Aktuální verze jádra: 3.3-rc6

Aktuální vývojová verze jádra je 3.3-rc6 vydaná 3. března. Linus říká, že se věci uklidňují: Už se to uklidnilo natolik, že by dokonce i *toto* mohlo být poslední -rc, ale uvidíme, jak to bude vypadat příští týden. Pokud to bude klidné jako doposud (a snad ještě klidnější), tak nevidím žádný velký důvod, proč tento vývojový cyklus dále protahovat.

Stabilní aktualizace: Verze 2.6.32.58 byla vydána 4. března. Obsahuje dlouhou řadu důležitých oprav. Greg k tomu napsal: Toto je poslední jádro 2.6.32, které vydávám. 2.6.32 nyní přechází do režimu „rozšířené dlouhodobé“ údržby, bez konkrétního plánu vydávání. DŮRAZNĚ doporučuji, aby teď všichni uživatelé jader 2.6.32 přešli na 3.0. Willy Tarreau ujistil, že převezme údržbu řady 2.6.32 – ale vydávat bude méně často.

Citáty týdne: Andrew Morton, Rusty Russel

Googlu se nějakým způsobem podařilo nahradit v adresářích různých lidí mé jméno jménem mého syna. Teď už je to pomíchané u akpm@linux-foundation.org stejně jako u akpm@google.com. V souboji proti pomíchání, absorpci a obecné asimilaci těchto identit prohrávám. A jak se podařilo Googlu zjistit, že jsme příbuzní? Napadá mě jen to, že to odhalil podle informací z Facebooku.

-- Andrew Matt Morton

Asi tak před dvěma lety, ještě než se Alex stala mou snoubenkou, jsme spolu mluvili o tom, co všechno lidé dělají pro dobrou věc. Prohlásila, že by si nikdy neoholila hlavu. Teď říká, že si tento rozhovor nepamatuje...

-- Ale Rusty Russel si takové věci vždy pamatuje; buďte varováni

Dva způsoby, jak počítat jadernou paměť

Řadič využití jaderné paměti umožňuje administrátorům omezovat to, kolik paměti je využíváno danou řídící skupinou. Je to užitečný nástroj pro systémy, kde je nutné na využití paměti aplikovat určitá pravidla – často jde o systémy, kde se používá virtualizace nebo kontejnery – ale má to jistou znatelnou nevýhodu: je sledována pouze paměť v uživatelském prostoru. Paměť používaná jádrem v rámci dané řídící skupiny není sledována. V některých situacích může být toto množství paměti znatelné; například taková řídící skupina, která přistupuje k velkému množství souborů, vytvoří velké množství položek v jaderné cachi položek adresářů („dentry cache“). Bez možnosti řídit používání paměti v jádře zůstává řadič paměti jen částečným řešením.

Vzhledem k tomu asi nepřekvapí, že patch, který tuto funkčnost doplňuje, už existuje. Trochu překvapivé už ale může být to, že existují dva nezávislé patche, které tuto funkci přidávají samy o sobě. Oba dva byly zaslány ke zhodnocení koncem února.

První patch poslal Glauber Costa, který už napsal řadič pro omezování TCP bufferů řídících skupin. Glauberův patch pracuje na úrovni slab alokátoru; aktuálně je podporován pouze alokátor SLUB. S tímto patchem musejí vývojáři pomocí následujícího rozhraní explicitně dávat najevo, že se má sledovat využívání u dané slab cache:

struct memcg_cache_struct {
	int index;
	struct kmem_cache *cache;
	int (*shrink_fn)(struct shrinker *shrink, struct shrink_control *sc);
	struct shrinker shrink;
};

void register_memcg_cache(struct memcg_cache_struct *cache);

Jakmile je slab cache předána do register_memcg_cache(), je v podstatě rozdělena do pole paralelních cachí, každá z nich přitom patří do jedné řídící skupiny spravované řadičem paměti. Díky navazující infrastruktuře pak každá z těchto slab cachí může sledovat, kolik paměti z ní bylo alokováno; tuto informaci lze pak využít k selhání alokace, pokud by mělo dojít k překročení omezení řídící skupiny. Ještě užitečnější je pak to, že řadič může po překročení limitů zavolat funkci shrink_fn(), která je přiřazena k dané cache; úkolem této funkce je najít paměť vhodnou k uvolnění a napomoci tak k tomu, aby se řídící skupina vrátila zpět pod nastavený limit.

Glauberův patch zahrnuje ukázku implementace pro dentry cache. Jakmile řídící skupina vytvoří dostatek dentries na to, aby překročila svůj limit, úklidová funkce může některé z nich odstranit. To může procesy v dané řídící skupině zpomalit, ale zajistí se tím to, že procesy vytvářející spousty dentries nebudou mít vliv na procesy v jiných řídících skupinách.

Druhý patch pochází od Suleimana Souhlala. I on se pro účely sledování využití paměti zaměřil na slab alokátor, ale v tomto případě jde o alokátor „slab“ namísto SLUB. Dalším významným rozdílem je to, že Suleimanův patch sleduje alokace ze všech cachí namísto sledování jen těch, které tak byly označeny. Přibyl příznak __GFP_NOACCOUNT, který explicitně zakáže sledování, ale celý systém funguje na tom principu, že se sledování musí vypínat namísto toho, aby se zapínalo. Někdo by sice mohl říkat, že pokud je sledování jaderné paměti důležité, tak by se měla sledovat všechna. Ale jak Suleiman přiznává, schopnost sledovat alokace ze všech cachí je také hlavní příčinou komplikovanosti patche.

Při tomto způsobu fungování pracuje slab cache stejně jako obvykle, dokud nedojde k alokaci z konkrétní cache, a to pod určitou řídící skupinou. V tento moment je cache automaticky rozdělena do jednotlivých cachí pro každou řídící skupinu bez možnosti zásahu (nebo vědomosti) toho, kdo volá. Toto rozdělování samozřejmě vyžaduje zamykání a alokaci paměti – což jsou operace, které mohou mít nežádoucí důsledky, pokud v daný moment systém zrovna běží v atomickém kontextu. V těchto situacích je rozdělování cache učiněno v úkolové frontě [workqueue] s tím, že aktuální alokace je vyřízena pomocí předrozdělené cache. Většina komplikovanosti v Suleimanově patchi pochází z tohoto zázračného rozdělování, které funguje nezávisle na kontextu, ze kterého probíhá volání.

V tomto patchi zatím není žádné rozhraní pro úklidové [shrinker] funkce, i když je toto plánováno do budoucnosti.

Při odstranění řídící skupiny obě implementace přesunou účtování paměti do nadřazené skupiny. Tato operace může také znamenat jisté komplikace, procesy, které učinily alokaci, mohou být stejně jako jejich řídící skupina v době uvolňování alokované paměti dávno ty tam. Glauberův patch u kořenové řídící skupiny neprovádí žádné účtování paměti; díky tomuto rozhodnutí (a důslednému programování) je pak režie sledování jaderné paměti prakticky nulová, pokud je sledování vypnuté. Suleimanův patch u kořenové skupiny vyžití sleduje, ale toto chování lze vypnout pomocí konfigurační volby jádra.

Ani jeden z těchto patchů není připraven k zařazení do hlavní řady před vývojovým cyklem verze 3.5 – a snad ani tehdy nebude. Je nutné dořešit velké množství detailů, mechanismy musí fungovat se slab i SLUB (přinejmenším) a nějakým zázračným způsobem se oba patche musí proměnit v jediné řešení. Oba vývojáři spolu komunikují a mají zájem spolupracovat, ale je jisté, že než dojde ke sloučení patchů, tak je bude muset někdo vést. Pokud mají uživatelé pocit, že sledování alokací ze všech cachí slab je důležité, tak je jasné, že to, co bude začleněno, bude muset takovou schopnost mít. Pokud se ale ukáže, že stačí sledovat několik velkých žroutů, tak postačí řešení, kde je nutné speciálně zapínat sledování. Prozatím se k tomu lidé moc nevyjadřovali; a než se vyjádří, tak bude těžké vědět, který přístup zvítězí.

Statistiky vývojového cyklu verze 3.3

V době psaní tohoto textu je vývojový cyklus 3.3 u verze 3.3-rc6 a začíná to vypadat dostatečně stabilně. Takže je čas podívat se na statistiky tohoto vývojového cyklu. Šlo o dosti aktivní cyklus s 10 350 sadami změn od více než 1200 vývojářů. Do jádra přibylo nějakých 563 000 řádek kódu, ale bylo také 395 000 řádek odstraněno, takže čistý přírůstek činí něco přes 168 000 řádek.

Nejaktivnějšími vývojáři byli:

Nejaktivnější vývojáři verze 3.3

Podle počtu sad změn Mark Brown 281 2.7% Mauro Carvalho Chehab 271 2.6% Axel Lin 240 2.3% Al Viro 200 2.0% Tejun Heo 123 1.2% Tomi Valkeinen 101 1.0% Russell King 100 1.0% Matthew Wilcox 99 1.0% Ben Skeggs 94 0.9% Johannes Berg 93 0.9% Stanislaw Gruszka 93 0.9% Kuninori Morimoto 92 0.9% Eliad Peller 90 0.9% Takashi Iwai 88 0.9% Eric Dumazet 87 0.8% Dan Carpenter 86 0.8% Franky Lin 77 0.8% Kalle Valo 74 0.7% Lars-Peter Clausen 73 0.7% Artem Bityutskiy 68 0.7%

Podle počtu změněných řádek Greg Kroah-Hartman 88664 11.7% Stanislaw Gruszka 38012 5.0% Mathieu Desnoyers 25968 3.4% Mauro Carvalho Chehab 21063 2.8% Alan Cox 20948 2.8% Kumar Gala 12083 1.6% Aurelien Jacquiot 9998 1.3% Mark Brown 9208 1.2% Evgeniy Polyakov 7979 1.1% David Daney 7684 1.0% Manuel Lauss 7316 1.0% Kuninori Morimoto 7115 0.9% Dmitry Kasatkin 6880 0.9% Jussi Kivilinna 6861 0.9% Ben Skeggs 6699 0.9% Axel Lin 6251 0.8% Jesse Gross 5940 0.8% Takashi Iwai 5140 0.7% Rob Clark 4962 0.7% Bart Van Assche 4711 0.6%

Mark Brown v seznamu nejvýznamnějších přispěvatelů figuruje pravidelně, v případě verze 3.3 přispěl velkým množstvím patchů v subsystémech pro zvuk a multifunkční zařízení. Mauro Carvalho Chehab je známější pro zařazování spousty změn ve Video4Linux2; tentokrát významnou část těchto patchů sám napsal. Příspěvky od Axela Lina šly taktéž do zvukového subsystému. Takže to lze shrnout tak, že tři nejaktivnější přispěvatelé do verze 3.3 všichni pracovali na multimédiích, což je zjevně oblast, kde se toho hodně děje. Al Viro ale není vývojář v oblasti multimédií; jeho prací bylo hlavně pročišťování rozhraní hluboko ve vrstvě virtuálního souborového systému (VFS). Tejun Heo se nadále hrabe v kódu napříč jádrem; tentokrát opravil alokátor memblock, udělal řadu vylepšení v zmrazovači procesů [process freezer], přepracoval plánovač pro blokové I/O CFQ a učinil řadu změn v řídících skupinách.

Co do počtu změněných řádek opět vede Greg Kroah-Hartman. Tentokrát téměř všechny jeho úpravy byly mazání; ze staging byla odstraněna spousta kódu, často díky tomu, že se kód probojoval do skutečné hlavní řady. Stanislaw Gruszka učinil spoustu změn v ovladači iwlegacy. Mathieu Desnoyers se do seznamu dostal díky přidání trasovacího subsystému LTTng; tento kód pak byl bohužel následně odstraněn a ve verzi 3.3 se tedy neobjeví. Alan Cox se dostal do první pětky díky své práci na grafickém ovladači gma500 a jeho přesunu ze stromu staging.

Do výčtu firem se dostalo něco přes 200 firem. Mezi nejaktivnější firmy patří:

Nejaktivnější zaměstnavatelé ve verzi 3.3

Podle počtu sad změn (žádný) 1322 12.9% Red Hat 1290 12.6% Intel 897 8.8% (Unknown) 524 5.1% Novell 450 4.4% Texas Instruments 422 4.1% IBM 357 3.5% Wolfson Microelectronics 282 2.8% Qualcomm 249 2.4% (Consultant) 243 2.4% MiTAC 240 2.3% Broadcom 231 2.3% Samsung 216 2.1% Google 211 2.1% Oracle 183 1.8% Freescale 163 1.6% Wizery Ltd. 111 1.1% Parallels 108 1.1% Renesas Electronics 104 1.0% (Academia) 102 1.0%

Podle počtu změněných řádek Novell 113910 15.1% Red Hat 111338 14.7% (žádný) 81133 10.7% Intel 68378 9.0% Texas Instruments 35696 4.7% Samsung 27220 3.6% EfficiOS 25990 3.4% Freescale 22266 2.9% (Unknown) 19307 2.6% (Consultant) 18529 2.5% IBM 16026 2.1% Wolfson Microelectronics 13688 1.8% Qualcomm 11736 1.6% Broadcom 11180 1.5% Mellanox 8856 1.2% Cavium 7903 1.0% Renesas Electronics 7574 1.0% Google 7135 0.9% MiTAC 6491 0.9% Nicira Networks 6004 0.8%

V této tabulce se v posledních letech mnoho nezměnilo; firmy, které figurovaly v jednom vývojovém cyklu, se povětšinou objeví i v cyklu následujícím. Je ale nutné poukázat na pokračující růst v počtu příspěvků od společností v oblasti mobilních a embedded zařízení. Tyto společnosti nedodávají jen podporu pro svůj hardware; čím dál více přispívají i do hlavních částí jádra a pomáhají posouvat jádro tím směrem, jaký je pro daný segment trhu potřeba. Dříve bylo možné slýchat nářky, že je vývoj linuxového jádra řízen potřebami nasazení ve velkých korporacích; teď už tomu tak moc není.

Další trend, který se podařilo vysledovat, je pomalý pokles podílu změn, které přicházejí od lidí, co na jádře pracují ve svém volném čase. Zde se můžete podívat na graf, ve kterém jsou zobrazena procenta pro všechna jádra od 2.6.25.

V číslech je vidět trocha šumu, ale trend za poslední čtyři roky ukazuje, že dobrovolníci nepřispívají tolik jako dřív. Není jasné, proč tomu tak je. Jednou možností je to, že jádro dospělo do stádia, kde už nezbývá mnoho jednoduchých úkolů; složitost vývoje současného jádra může dobrovolníky odrazovat. Nebo může prostě jít o to, že kdokoliv prokáže schopnost dostat svůj kód do jádra nezůstává dlouho dobrovolníkem, leda by to tak skutečně chtěl; všichni ostatní dostanou nabídku na zaměstnání. Pravda může ležet někde mezi – nebo taky někde úplně jinde.

Dobrovolní vývojáři jsou důležití; pomáhají spojovat jádro se širší komunitou a někteří z nich se další rok stanou profesionálními vývojáři a správci subsystémů. Jádro, které není pro dobrovolníky zajímavé, se může v budoucnu potýkat s nedostatkem vývojářů. Prozatím nic nenapovídá tomu, že by se takový nedostatek blížil; jádro 3.3 s 1200 přispěvateli není o nic slabší než ta předchozí. Tak či tak ale stojí za to tento trend sledovat.

Celkově však jádro nadále vypadá jako zdravý a rychle se rozvíjející projekt. K vydání verze 3.3 by mělo dojít někdy kolem půlky března, přesně podle plánu. Už teď se vynořuje spousta zajímavého kódu pro začlenění do verze 3.4; až si budete za nějakých 80 dnů číst pokračování tohoto přehledu, uvidíte jistě další vysoká čísla.

Diskuse k tomuto článku

[David Jaša]

typo: Glauer

[Marián Kyral]

A taky:

Co do poštu změněných řádek

[Lampa]

Opravdu je Andrew Mortin ?

[Honz]

Vlasy se neholí, ale stříhají. Holí se hlava.

[Marián Kyral]

No pokud chceš mít hlavu opravdu holou, tak ti nůžky nestačí.

[Suchý čert]

On chtěl spíše asi poukázat na určitou nelogičnost toho slovního spojení, logicky by mělo cílem holení X být holé X, tedy například, že se holí tvář, a ne vousy. Běžně se ale používají i ty „nesprávné“ varianty…

[Šangala]

A neholí se vousy ale brada, že?!

[Pev]

typo: změn v ovladači iwlegacy

[Luboš Doležel (Doli)]

Snad jsem všechny nahlášené překlepy opravil, díky. Psal jsem to na jiné klávesnici