Jaderné noviny – 27. 7. 2012: Co bude v jádře 3.6

13. 8. 2012 | Luboš Doležel | Jaderné noviny | 3690×

Aktuální verze jádra: 3.5. Citáty týdne: Arjan van de Ven, Mike Galbraith. Vyšlo CRtools 0.1. Co bude v jádře 3.6, část první. Kdo napsal jádro 3.5.

Obsah

• Aktuální verze jádra: 3.5
• Citáty týdne: Arjan van de Ven, Mike Galbraith
• Vyšlo CRtools 0.1
• Co bude v jádře 3.6, část první
• Kdo napsal jádro 3.5
  • Jádro rychlých změn
  • Individuální příspěvky
  • Revidování práce
  • Kdo tuto práci zaplatil
  • A jede se dál

Aktuální verze jádra: 3.5

Jádro verze 3.5 vyšlo 21. července; pro podrobnosti vizte Linusovo oznámení. Hlavní novinky jsou algoritmus CoDel pro správu front (část řešení problému bufferbloat), mechanismus sandboxu skrze filtry seccomp, autosleep (alternativa k oportunistickému uspávání na Androidu), subsystém uprobes, alokátor souvislé paměti, nové systémové volání kcmp(), kontrolní součty metadat v ext4 a ještě více. Více naleznete na příslušné stránce na KernelNewbies.

Stabilní aktualizace: verze 3.0.38 a 3.4.6 vyšly 19. července s obvyklou dávkou důležitých oprav. Aktualizace 3.2.24 se aktuálně reviduje.

Citáty týdne: Arjan van de Ven, Mike Galbraith

Policie magických konstant a bílých znaků představují v linuxovém jádře obdobu letištních kontrolorů. Teoreticky tu jsou proto, abychom byli v bezpečí, ale všichni si potají myslí, že to dřív byli malí kluci, na které si ve školce ostatní akorát dovolovali, a tohle je jejich odplata zbytku populace.

-- Arjan van de Ven

Ať už to nakonec smysl má, nebo ne, tak jsem pro backportování výkonnostních vylepšení. Mají ale jednu nevýhodu (kromě rizika zavlečení chyb nebo vyvolání skrytých chyb).

Když se sestavuje další verze enterprise jádra, tak se markeťáci ptají na čísla, nad kterými potenciální zákazníci budou slintat, jenže vy nemůžete žádná vyrobit, protože jste všechny výkonnostní úpravy už nacpali do toho přestárlého jádra.

-- Mike Galbraith

Vyšlo CRtools 0.1

Na blogu OpenVZ vyšlo oznámení vydání CRtools 0.1. Našim hlavním cílem je dostat všechny kousky OpenVZ do hlavní řady jádra. Není tajemstvím, že jsme se začleňováním funkčnosti checkpoint/restore (CPT) naprosto selhali (a ano, zkusili jsme to vícekrát). Skutečnost, že se to nepovedlo ani jiným, nás trochu utišuje, ale ničemu to nepomáhá. Důvod je prostý: kód CPT je obrovský, komplexní a zasahuje do mnoha míst v jádře. Takže jsme přišli s nápadem implementovat většinu funkčnosti CPT v uživatelském prostoru, tedy jako program nezávislý na linuxovém jádře. Prakticky je to nemožné, protože sem a tam jsou stále nezbytné nějaké ty jaderné triky, ale cílem bylo omezit zásahy do jádra na naprosté minimum. A to byste nevěřili, dopadlo to líp, než jsme čekali. Dnes, asi tak po roce vývoje, je až 90 % nutných věcí v jádře a zbytek je na cestě a mělo by být relativně snadné jej začlenit.

Co bude v jádře 3.6, část první

Linus obvykle čeká asi tak den po velkém vydání, než začne začleňovat patche v dalším cyklu, ale v případě 3.6 začal rovnou. V době psaní textu se do hlavní řady dostalo už nějakých 4300 neslučovacích změn; většina se zatím týkala sítí a ARMu. Významné změny viditelné uživatelům zahrnují:

• Subsystém událostí perf má nyní podporu pro jednotky meření výkonu „uncore“ na procesorech Intel Nehalem a Sandy Bridge.
• Architektura x86 nyní podporuje volby reboot=bios a reboot-cpu na 64bitových procesorech (stejně jako na 32bitových, kde to už bylo podporováno dlouho).
• „Uspání oběma způsoby“ umožňuje uspání po zapsání obrazu hibernace na disk. Pokud by došlo k výpadku napájení, tak se pak systém může opět spustit z obrazu na disku.
• Nyní je podporováno rozšíření CANFD pro controller area network (CAN).
• Spousta modulů netfilter získala náležitou podporu jmenných prostorů Byla začleněna i pomocná infrastruktura pro sledování spojení v uživatelském prostoru.
• Vrstva Bluetooth nyní podporuje „UART o třech vodičích“, což umožňuje Bluetooth operace po sériové lince.
• Byl začleněn patch pro malé fronty TCP, což je další část řešení problému bufferbloat.
• Bylo začleněno rozšíření fast open [rychlé otevření] protokolu TCP. TCP fast open je patch z Google, který snižuje režii vytváření spojení TCP, což by snad mělo protokoly jako HTTP urychlit.
• Dlouhodobá snaha o odstranění kódu routovací cache IPv4 ze subsystému síťování se dostala ke svému závěru. David Miller k tomu napsal:

  Routovací cache IPv4 je co do výkonnosti nedeterministická a dá se snadno zneužít k útokům DoS. Routovací cache pracuje správně s dobře se chovajícím provozem a svět byl mnohem přátelštějším místem, když se zvažovaly kompromisy, které určily podobu routovací cache.

  Následkem je to, že výsledný výkon routovací cache je tvarován chováním síťového provozu, jak jej vidí systém, namísto obrazem obsahu routovacích tabulek.

  Náhradní kód zjednodušuje síťový subsystém a snad i přináší vyšší výkon na systémech s vysokou zátěží.

• Podpora nového hardwaru.

Změny viditelné vývojářům jádra zahrnují:

• Zastaralé rozhraní static_branch() bylo odstraněno ve prospěch static_key_true() a static_key_false(). Více na toto téma v tomto článku.
• Začalo se dělat na oddělení kódu dynamických tiků od idle úlohy, což je základ pro zastavení tiku hodin na CPU bez idle.
• Subsystém výkonnostních domén [power domains] se dočkal určité integrace s kódem cpuidle, aby bylo možné řešit situace, kdy zařízení sdílejí přítok proudu s jádry CPU.
• Vrstva VFS se dočkala významných změn. Přibyla nová operace nad inode atomic_open(), které kombinuje proces vyhledání, případně vytvoření a otevření souboru v jediné, atomické operaci. Mechanismus „úmyslů otevření [open intents]“ byl odstraněn. Řada jiných operací má teď jiný prototyp. Byly začleněny změny odloženého fput(), což usnadňuje proces pročišťování struktur pro soubory.
• Architektura PowerPC nyní podporuje mechanismus skokových návěstí [jump label].
• Z rozhraní netlink zmizela makra NLMSG() a NLMSG_PUT().
• Subsystém pro vstup má nové rozhraní pro vytváření ovladačů pro uživatelský prostor; více v dokumentaci uhid.
• Pro jednotky správy I/O paměti je tu nový mechanismus shlukování s cílem usnadnit bezpeční přístup k zařízením pro virtualizované hosty.

Dá se očekávat, že toto začleňovací okno potrvá asi až do 4. srpna, takže se do něj dostane docela dost kódu, než vyjde -rc1. Příští týden se dozvíte o dalších věcech, co se do 3.6 dostaly.

Kdo napsal jádro 3.5

Teď, když vyšlo jádro 3.5, je čas se podívat na to, kdo za ním stál. Nyní následuje souhrn toho, kdo odvedl všechnu tu dřinu, která se do tohoto vydání dostala.

Jádro rychlých změn

Jádro 3.5 vyšlo o den dříve než 3.4, tedy během 62 dnů. Jádro vyšlo takhle rychle naposledy v roce 2005, to byla verze 2.6.14 (61 dnů).

Během těchto 62 dnů vývojáři dodali rekordních 176,73 změny za den (7,36 změny za hodinu). To je nejvyšší rychlost od doby, co to je (autorem původního textu) od řady 2.5 sledováno.

Tyto změny daly v součtu tento výsledek:

Změny v 3.5
571987	řádek přidáno
358836	řádek odstraněno
135848	řádek změněno

Jádro vytrvale roste s docela konstantní rychlostí 1,37 %, co do růstu počtu řádek a souborů, což je podobné rychlosti růstu tří předchozích jader.

Individuální příspěvky

1195 různých vývojářů přispělo patchi do jádra 3.5; tito vývojáři pracují pro přinejmenším 194 různých firem.

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

Podle sad změn Greg Kroah-Hartman 239 2.2% Axel Lin 191 1.7% Mark Brown 187 1.7% H. Hartley Sweeten 135 1.2% David S. Miller 131 1.2% Daniel Vetter 130 1.2% Al Viro 128 1.2% Stephen Warren 121 1.1% Tejun Heo 112 1.0% Eric Dumazet 105 1.0% Hans Verkuil 102 0.9% Paul Mundt 102 0.9% Johannes Berg 102 0.9% Shawn Guo 102 0.9% Thomas Gleixner 98 0.9% Dan Carpenter 86 0.8% Sam Ravnborg 84 0.8% Chris Wilson 79 0.7% Trond Myklebust 74 0.7% Eric W. Biederman 73 0.7% Jiri Slaby 73 0.7% Arnaldo Carvalho de Melo 71 0.6% Artem Bityutskiy 68 0.6% Hans de Goede 68 0.6% Takashi Iwai 64 0.6%

Podle změněných řádek Paul Gortmaker 44000 5.7% Viresh Kumar 20425 2.7% Steven Rostedt 14615 1.9% H. Hartley Sweeten 13083 1.7% Dave Airlie 12217 1.6% Sakari Ailus 10835 1.4% Dong Aisheng 10574 1.4% Sonic Zhang 10494 1.4% Paul Walmsley 10084 1.3% Ben Skeggs 10000 1.3% Rob Herring 9886 1.3% Sascha Hauer 9602 1.3% Stephen Warren 9365 1.2% Parav Pandit 8846 1.2% Nicholas Bellinger 8704 1.1% Linus Walleij 8496 1.1% Shawn Guo 7797 1.0% David S. Miller 7445 1.0% Phil Edworthy 7189 0.9% Sam Ravnborg 6752 0.9% Hans Verkuil 6718 0.9% Alexander Shishkin 6668 0.9% Tejun Heo 6579 0.9% Greg Kroah-Hartman 6524 0.9% Vladimir Serbinenko 6451 0.8%

Revidování práce

Všechny patche jsou revidovány a podepsány („Signed-off-by“) správcem subsystému před tím, než jsou začleněny do jádra. Vývojáři, kteří toho pro jádro 3.5 podepsali nejvíc, jsou tito:

Vývojáři s co nejvíce podpisy (celkem 20391)
Greg Kroah-Hartman	1216	6.0%
David S. Miller	922	4.5%
Mauro Carvalho Chehab	605	3.0%
Mark Brown	549	2.7%
John W. Linville	493	2.4%
Linus Torvalds	424	2.1%
Andrew Morton	373	1.8%
Daniel Vetter	268	1.3%
Dave Airlie	255	1.3%
Al Viro	197	1.0%
Axel Lin	191	0.9%
Trond Myklebust	173	0.8%
Arnaldo Carvalho de Melo	165	0.8%
James Bottomley	164	0.8%
Artem Bityutskiy	157	0.8%
Kyungmin Park	156	0.8%
Samuel Ortiz	154	0.8%
Linus Walleij	153	0.8%
Ingo Molnar	150	0.7%
Wey-Yi W Guy	146	0.7%
Thomas Gleixner	139	0.7%
Stephen Warren	136	0.7%
H. Hartley Sweeten	135	0.7%
Shawn Guo	131	0.6%
Paul Mundt	128	0.6%

Tato čísla odráží obraz toho, co se událo v posledních několika vydáních jádra, většina změn se stala v oblastech staging a síťování.

Kdo tuto práci zaplatil

Zde je seznam firem, které zaplatily vývojáře pracující na této verzi jádra (a k tomu počty změn).

Největší přispěvatelé dle zaměstnavatelů
(None)	1343	12.3%
Red Hat	1123	10.2%
Intel	1061	9.7%
(Unknown)	860	7.8%
Linaro	519	4.7%
Novell	440	4.0%
Texas Instruments	313	2.9%
IBM	282	2.6%
Linux Foundation	279	2.5%
Google	265	2.4%
Samsung	251	2.3%
Oracle	204	1.9%
Renesas Electronics	201	1.8%
MiTAC	191	1.7%
NVIDIA	188	1.7%
Wolfson Microelectronics	187	1.7%
(Consultant)	160	1.5%
NetApp	153	1.4%
Vision Engraving Systems	135	1.2%
Qualcomm	121	1.1%

Dlouholetí čtenáři si jistě všimli, že se Linaro objevilo v top 5 firmách poprvé. To je kvůli zvýšenému počtu patchů, kterými Linaro přispívá, stejně tak ale i kvůli tomu, že členské firmy chtějí, aby se příspěvky kódu počítaly pod Linaro a ne pod členskou firmu, jako to bylo dřív.

Nováčkem v top 20 je Vision Engraving Systems, a to díky práci na Comedi od H. Hartleyho Sweetena. Díky jeho práci se tento subsystém snad konečně dostane ze staging.

Kromě velkého skoku Linaro jsou ostatní firmy v top 25 dobře známé. Dokonce i NVIDIA – navzdory medializované kritice od Linuse Torvaldse – je nadále velkým přispěvovatelem do jádra v oblasti embedded procesorů (pro své produkty). Texas Instruments, Samsung, MiTAC, Wolfson Microelectronics, Qualcomm, Renesas a Nokia jsou také zaměřeny na oblast embedded Linuxu.

A jede se dál

S vydáním verze 3.5 zůstává počet příspěvků stejně velký jako u ostatních vydání, rychlost příspěvků je ale větší než kdy předtím (dle počtu patchů za den) a rychlost růstu velikosti jádra zůstává za poslední rok stejný. To ukazuje, že jaderná komunita vytrvale roste a udržuje svůj neuvěřitelně rychlý vývojový cyklus, což znamená, že Linux je nadále největším softwarovým projektem, co kdy byl.

       

Komentáře

[100% Lenin]

Первый.

[berger]

Zdravim,

na zaciatok vdaka za dobru pracu pri preklade, ale naslo sa par zabudnutych veci. Pri druhom citate chyba meno autora (-- Mike Galbraith). Dalsia vec, ktoru som si vsimol: Takže jsme přišli s nápadem implementovat většinu funkčnosti CPT v jádře, tedy jako program nezávislý na linuxovém jádře.

V originali je user space. Z mojho pohladu sa asi stala chyba a namiesto mimo jadra, sa objavilo v jadre.

[Luboš Doležel (Doli)]

Díky, opraveno.

[Sten]

Obojetné uspání mi přijde jako úplně úžasná fíčura. I v Redmondu se totiž systém musí probudit, aby se hibernoval, na což ale někdy nemusí mít dost baterie (a někdy ani žádné baterie nemá).

[R]

IBM to malo uz pred 18 rokmi v ThinkPadoch - pod nazvom RediSafe. Myslim, ze teraz to ma MacOS X.

[tom]

Todle umely bezne thinkpady z minuleho tisicileti, bylo to implementovane castecne v biosu. Dalo se to nastavit i tak, ze se system uspany do ram vzbudil, kdyz zjistil, ze mu dojde stava, a pak se uspal na disk.

[Sten]

To, že se systém vzbudí, když mu dochází baterie, dělá už dneska cokoliv s Windows nebo Linuxem, ale osobně mám vyzkoušené, že to není úplně spolehlivé (baterie může dojít během hibernace, když už je stará a má hodně malou kapacitu, a nejde to na desktopu) a navíc, když při uspání zahodím klíč k LUKS, tak to kromě vzbuzení nic neudělá.

[tom]

Po probuzeni to skocilo do firmware notebooku, ktery provedl uspani na disk. Interakce systemu IMO nebyla potreba.

[Sten]

To bych se divil a současné systémy to tak ani nedělají. Kam by se to uspalo, když disk je šifrovaný klíčem, který není k dispozici? A kdo by zrestartoval všechny periferie, které se při uspání do RAM nevypínají/nemažou, ale při hibernaci se vypnou (třeba USB nebo cache procesoru)?

[tom]

Uspavalo se to na partitionu, ktera k tomu byla vyhrazena. Pouzivalo to nejaky vlastni format. Periferie se v dobe pred 12lety mohli chovat jinak, pamatuji si jen, ze to neslo probudit USB klavesnici. Duvodem mohl byt i fakt, ze uspany notebook mohl byt vyndan z doku, v kterem byl i jeden PCI slot.

[tom]

A taky to vydrzelo v RAMce uspane mnohem dele - pamatuji si, ze jsem po posledni cervnove zkousce NTB zavrel a pak ho v zari otevrel a on nabehl z RAMky :)

[Jendа]

když při uspání zahodím klíč k LUKS, tak to kromě vzbuzení nic neudělá

Zahazuješ i klíč k /? Používáš ten Mrkvův patch, nebo jsi to vyřešil nějak jinak?

[Sten]

Mrkvův patch neznám, ale řešil jsem to tak, že screensaver a cryptsetup (včetně knihoven) zkopíruju do tmpfs. Ale kvůli tomu, že se to neumí vzbudit a zahibernovat, to nakonec nepoužívám.

[Honza Jaroš]

Neuměl tohle i swsusp2/TuxOnIce? Mám neodbytný pocit, že jsem kdysi něco takového zkoušel...

[Václav HFechs Švirga]

Co vim, tak umi, asi to je akorat tedka uz v jadre, driv to bylo asi nejak externe.

[Jendа]

Určitě, na Archu kolem 2.6.30 jsem měl s2both. Proto nechápu ty bombastické články.

[Václav HFechs Švirga]

Takova ficura mi neprijde k nicemu, pokud chci uspani do ram, chci to proto, at se to uspi rychle. Treba konec prednasky, chci uspat (i s vizualni kontrolou, ze se skutecne ntb uspal, protoze v Linuxu se to nekdy na necem sekne a pak by byl ntb zaply v brasne), nacpat do brasny a jit pryc. Pri obojetnem uspani ale musim cekat uplne stejne dlouho jako pri uspani na disk, jedina vyhoda je ta, ze se mi to rychleji zapne. Ale to je mi uplne k nicemu, ja to potrebuji rychle schovat .

Naopak ficura typu, ze se ntb uspany do ram pri 1 % baterky sam probudi a zasuspenduje se mi prijde podstatne uzitecnejsi (a musi mit hw podporu), nicmene lepsi je to samozrejme nenechat do takoveho stavu dojit. Pokud mam jen par procent baterky, o suspendu do ram se nepokousim, pokud je baterka aspon na 25 %, tak to vydrzi i den.

[Sten]

S automatickým probuzením je jeden problém: co když se to probudí v tašce, kde to má i během hibernace velkou šanci se přehřát?

Jinak bych to samozřejmě viděl jako další možnost, nikoliv jako náhradu samotného uspání

[Jendа]

Jakou tak může mít tepelnou kapacitu notebook? 1 kJ/K? Tak to se za minutu (tak dlouho může trvat uspání) při příkonu 20 W ohřeje o stupeň.

[Václav HFechs Švirga]

Tak můj "thinkpad" (SL model) byl zaplý v těsném neprodyšném prostoru asi hodinu (právě kvůli nějakému bugu při uspávání, kdy jsem to pak nezkontroloval :/), když jsem ho vytahoval, tak jsem si spálil pracky, protože byl žhavý úplně všude. Byl zaseklý a když jsem ho zrestartoval, jen zapípal že je přehřáty, zapnout šel až po čtvrthodince kdy se už dostatečně ochladil (ale horký byl ještě tak 2 hodiny ). Žádné následky to ale naštěstí nezanechalo.

Nicméně i tak by takové probuzení nemuselo být veselé a to ne kvůli přehřátí, ale možnosti poškození hdd. Ale to už je každého věc, jaké uspání si zvolí dle situace. Máme 4 alternativy: na disk, do ram, do ram s případným probuzením a zapsáním na disk, do ram i na disk. Každé má své výhody a nevýhody a záleží na situaci.

[Ondrej 'SanTiago' Zajicek]

co když se to probudí v tašce, kde to má i během hibernace velkou šanci se přehřát?

No, horsi asi bude, kdyz se probudi zrovna ve chvili, kdy s nim v batohu na zadech nekde bezim nebo jedu na horskem kole krajinou (a notebook ma klasicky HDD).

[Kvakor]

A pokud máte starší notebook, kde baterie už má nejlepší léta za sebou a funguje spíš jako vestavěné UPSka, tak se obojetné uspání hodí, protože pokud se notebook v suspendu vybije "do mrťe", tak se místo normálního startu (a kontroly disků) protě jen odhibernuje.

[Václav HFechs Švirga]

Toho jsem si samozřejmě vědom, pokud by to fungovalo dobře, klidně bych u sebe uspání na disk v situacích, kdy ho potřebuju, nahradil tímto (pokud se baterka nevybije, mám šanci, že se mi ntb probudí rychleji - co víc si přát...), ale pokud potřebuju ntb rychle uspat a schovat, tak mi je tohle na nic, protože někdy se mi ta ram do swap oddílu zapisuje i 5 minut :-/, naopak uspání do ram je rychlejší než vypnutí!

[Jendа]

Mně se zase líbí to rychlé zapnutí. Ale samovznícení samoprobuzení už jsem asi dvakrát zažil :(.

Nicméně u mého EE není spotřeba v s2ram tak velká, aby se vyplatilo tlačit ten gigabajt na disk (protože disk nedá ani 20 MB/s ).

[Ondrej 'SanTiago' Zajicek]

EE ma jen 2/3 spotreby bezneho EEE? ;&ndash)

[Jendа]

Nevšiml jsem si, že by se po tom, co jedno E upadlo, snížila spotřeba .

[2X4B-523P]

asus k53sv s Debian wheezy se mi při slabé ze spánku probudí a sám zahibernuje, poprvé mě to vyděsilo a docela jsem zíral, že ta fičura takhle fachá sama od sebe jak to bude se starou baterií uvidím, můj funguje od prosince a používám baterii denně... baterii podle mého zabije trvalé připojení notebooku do el. sítě...

[Jendа]

baterii podle mého zabije trvalé připojení notebooku do el. sítě

Proč proboha?

[David Jaša]

Zkus pracovat s notebookem co rok nebyl mimo síť (tedy s baterkou o 0 cyklech) a pochopíš.

[chachar87]

tak ja takhle provozuju svuj ntb doma a nemam problem...ntb uz bude starsi tri let a z toho ty dva roky to provozuju trvale pripojene do site...vyjimecne jedu jenom z baterky ale kdyz jo tak vydrz pres 3 hodiny...kde je problem?

[David Jaša]

Tak to máš (mnou) nevídané štěstí na kvalitu elektroniky baterky.

[chachar87]

aspon neco to HPecko udelalo dobre, kdyz uz to chlazeni stoji za vyliz prdel :)

[Gilhad]

Tak nevim, ja mam NB pripojeny do site skoro porad (rekneme minimalne 24 h/denne, po 6 dni v tydnu) a po nekolika letech je baterie sice slabsi nez na zacatku, ale nijak zvlast vyrazne. Spis se mi zda, ze v porovnani s tim, jak zhuntovana by mela byt pri "beznem a planovanem" pouzivani, tak je stale jeste prekvapive dobra a lepsi, nez se planovalo.

[Michal Kubeček]

Nějak jsem si vsugeroval, že odstranění routing cache bude až ve 3.7, tak díky za vyvedení z omylu.

[Harvie.CZ]

Vtipnej dusledek asi bude, ze konkurencni vServer pravdepodobne dostane podporu checkpointovani na disk aniz by jeho vyvojari museli napsat vic nez par radek v bashi... vServer je proti OpenVZ spoustu let za opicema, ale i tak to treba oddali migrace z vServeru na OpenVZ u lidi, ktery potrebujou OpenVZ primarne kvuli checkpointovani...