Současné vývojové jádro je 2.6.32-rc5, vydané Linusem 15. října. 90% z hlavní části změn od -rc4 je v ovladačích, většina z toho pochází ze dvou síťových ovladačů (stmmac a vmxnet3). Kromě nových ovladačů je zde téměř 300 commitů a většina z nich jsou poměrně rozprostřené jedno- nebo málořádky: aktualizace v architekturách (arm, powerpc, x86), nějaké aktualizace v souborových systémech (hlavně btrfs) a nějaká dokumentace, síťování atd. Zkrácený changelog je v oznámení, detaily vizte v kompletním changelogu.

Vzhledem ke Kernel Summitu nebyly do hlavní řady od vydání 2.6.32-rc5 začleněny žádné změny.

Během minulého týdne nevyšly žádné stabilní aktualizace. V době psaní tohoto článku je revidováno 2.6.31-rc5; až toto budete číst, dost možná bude k dispozici.

Citáty týdne

Pokusně jsem do mailové konference Linux kernel poslal testovací případ. Nevěděl jsem, co očekávat; možná další hádky přenesené z debaty o BFS? Místo toho jsem dostal "Díky za hezké a opakovatelné testy!" To je jeden z mála případů, které jsem viděl mimo to, o co se pokouším u x264: vývojáře, kteří jsou rádi, že jim někdo ohlásil chybu v kódu, a kteří se zjevně chystají ji opravit. I když to doteď znělo docela dobře, bude to mít nějaké výsledky?

Odpověď: ano - až 70% nárůst výkonnosti, který byl začleněn o den později. Vývojáři jádra tím ale neskončili: rychlý grep e-mailů na Linux Kernel během několika dalších týdnů ukázal, že se v poměrně mnoha benchmarcích objevuje x264. Stal se z toho běžný test. A právě nedávno jsme získali dalších 10% výkonnosti navíc.

S něčím, co vypadá jako svinstvo, by se nemělo zacházet nijak zvláštně a nechávat to v jádře jenom proto, že by to 'mohlo' být ne-svinstvo.

Výsledky voleb LF TAB 2009

Jedna z často přehlížených událostí, která se každoročně odehrává na Jaderném summitu, je obsazování pěti z deseti míst ve Výboru technických poradců [Technical Advisory Board] Linux Foundation. Výbor je pověřen zprostředkováváním výměny informací mezi LF a vývojovou komunitou. Ve volbách roku 2009 se v Tokyu vybíralo z velké skupiny kandidátů. Výherci byli Greg Kroah-Hartman, Alan Cox, Thomas Gleixner, Ted Ts'o a redaktor LWN.net Jonathan Corbet. Druhou polovinu výboru (které končí mandát za rok) tvoří James Bottomley, Kristen Carlson Accardi, Chris Wright, Chris Mason a Dave Jones.

Jaderný summit 2009

Jaderný summit, ročník 2009, se konal v Japonsku v Tokyu 19. a 20. října. Časovým posunem dezorientovaní vývojáři z celého světa diskutovali široký záběr témat. Jonathan Corbet, redaktor LWN, byl při tom a sepsal následující shrnutí:

Den 1.

Den 2.

Jaderný summit skončil s obecným pocitem, že diskuze probíhaly dobře. Také bylo poznamenáno, že japonští hostitelé odvedli v podpoře summitu výjimečný kus práce a tím umožnili, aby se všechno odehrálo; nebylo by překvapením, kdyby vývojáři navrhovali, aby se summit v blízké budoucnosti do Japonska vrátil.

Díry v souborech, souběhy a mmap()

Souborové operace používající truncate() vždy obsahovaly souběhy. Vývojáři vždy měli obavy z toho, že dojde k souběhu zápisu do souboru a změně jeho velikosti. Existují různé krajní případy, ve kterých mohou být ztracena nebo ignorována data nebo ve kterých se naopak mohou objevit data tam, kde jsou v dírách v souboru očekávány nuly. Patch Jana Káry se pokouší takové souběhy opravit a závisí přitom na nové sekvenci zkracování, která opravuje způsob, jakým je nastavována velikost inodu souboru.

Díry

Díra je v souboru oblast reprezentovaná nulami. Vznikne, když se zapíší data na pozici [offset] v souboru, která je za současnou velikostí, nebo když je soubor "zkrácen" na délku větší, než je jeho současná velikost. Místo mezi původní velikostí souboru a pozicí (nebo novou velikostí) je vyplněno nulami. Většina souborových systémů je dostatečně chytrá a nuly vyznačí v inodu, neukládá je fyzicky na disk (takové soubory jsou také známy jako řídké [sparse]). Souborový systém označí bloky v inodu a poznamená v nich, že jsou součástí díry. Když uživatel požaduje data z pozice v díře, souborový systém vytvoří stránku vyplněnou nulami a předá ji do uživatelského prostoru.

Práce s dírami začne být trochu ošidná, když díry nejsou zarovnané podle hranic bloků v souborovém systému. V takovém případě je nutné část bloků reprezentující díry vynulovat. Například soubor o velikosti 12k na souborovém systému s velikostí bloku 4k a s dírou o velikosti 8192 od pozice 2500 bude vyžadovat, aby posledních 1596 (4096-2500) bytů prvního bloku a stejně tak prvních 2500 bytů třetího bloku bylo vynulováno. Druhý blok je v seznamu datových bloků inodu vynechán a nezabírá žádné místo na disku.

Mmap

mmap() je systémové volání, které mapuje obsah souboru do paměti. Volání přebírá adresu, kam má být soubor namapován, popisovač souboru, pozici v souboru, odkud se má mapovat a délku dat od této pozice. Obvykle se jako adresa předává NULL, takže si adresu může vybrat jádro procesu ji předat. Mmap lze provést dvěma způsoby:

Když proces zavolá mmap(), jádro nastaví oblast adres virtuální paměti (Virtual Memory Address - VMA - region), do které mapuje stránky souboru na disk. Do vma->vm_ops přiřadí struct vm_operations souboru. struct vm_operations obsahuje ukazatele na funkce, které pomáhají dostat na vyžádání stránky do paměti. vm_operations.fault() se volá, když uživatel přistoupí do oblasti virtuální paměti, která v hlavní paměti není přítomna. Je zodpovědná za načtení stránky z disku a její vložení do paměti. Pokud je vma sdílená, vm_operations.page_mkwrite() nastaví stránku jako sdílenou, v opačném případě je duplikována pomocí COW. page_mkwrite() zodpovídá za sledování informací, které potřebuje souborový systém, aby bylo možné data umístit zpátky na disk (například buffer_heads). To typicky znamená přípravu bloku na zápis, kontrolu, jestli je dostatek místa na disku (a vrácení ENOSPC, když není), a provedení zápisu.

U současné sekvence page_mkwrite() hrozí souběh se změnami velikosti souboru způsobenými truncate(). Zkracování souboru probíhající ve chvíli, kdy jsou data ze sdíleného mmap() zapisována zpět na disk, mohou vést k nepředvídatelným výsledkům, jako je ztráta dat nebo jejich objevení se na místě, kde čekáme nuly.

Ztráta dat

Ztráta dat může v programu nastat ve specifickém případě, kde program namapuje soubor do paměti větší, než je současná velikost. Jak může ke ztrátě dojít, ukazuje následující úryvek kódu na systému s velikostí bloku 1024 bytů a velikostí stránky 4096 bytů:

Všimněte si, že i když je velikost souboru nastavena na 1024 bytů, mapováno je jich 4096, což je více než současná velikost. To je přípustné, protože stránky souboru jsou mapovány se zarovnáním na velikost stránky. Vzhledem k tomu, že ve sdílené paměti dochází ke změně, záznam v tabulce stránek se nastaví na zapisovatelný.

Když je poprvé voláno page_mkwrite(), je alokován pouze blok 0, protože velikost souboru se vejde do 1024 bytů. Když nicméně program zvětší velikost souboru a zavolá fsync(), writepage() potřebuje alokovat další 3 bloky, aby mohl provést zápis vyvolaný map[3000]. Pokud je v takové situaci vyčerpána kvóta uživatele nebo souborový systém již nemá volné místo, data modifikovaná zápisem do map[3000] jsou v tichosti ignorována.

Neočekávaná data v díře

Nenulový znak se v díře může objevit, pokud proces zemře po rozšíření souboru, ale před vynulováním stránky a zápisem do ní. K pochopení problému nám pomůže tento úryvek kódu:

Program nepřetržitě zapisuje na pozici 1020. Jádro před zápisem na disk vynuluje stránky od pozice 1000 do 4096. map[1020] může být nicméně nastaveno poté, co jádro stránku vynuluje. Stránka je odemčena a nastavena pro zpětný zápis. V takovém případě je na disk zapsán nenulový znak. To není problém, protože je mimo rozsah souboru. Když ale jiný proces soubor zvětší (a tím zvětší i díru) a je zabit předtím, než stránku znovuvynuluje a zapíše, bude v souboru při příštím čtení obsažen "špinavý znak". Tento problém existuje bez ohledu na velikost bloku souborového systému. Kompletní program, který tento problém demonstruje, lze najít zde.

Řešení

Janův patch zavádí pomocné funkce, které zajišťují vytváření děr: block_prepare_hole() a block_finish_hole(). Tyto funkce jsou volány v sekvencích write_begin() a write_end() operací s adresovým prostorem, pokud je zjištěno, že současná pozice v souboru je větší, než současná velikost, tj. při vytváření děr. write_begin() a write_end() jsou obvykle volány v page_mkwrite(). Část stránky, která reprezentuje díru, je místo v block_write_full_page() nulována v block_prepare_hole(). Během celé sekvence page_mkwrite() je stránka uzamčena, takže je chráněna proti zápisům jinými procesy. Operace zkrácení může proběhnout, až když je zámek stránky uvolněn, což sekvenci řadí. To řeší problém zbloudilých dat, která mohou v díře přistát.

Na druhou stranu block_finish_hole() je zodpovědná za označení části stránky v díře jako pouze pro čtení. Pokud se proces pokusí cokoliv zapsat do té části díry, která patří stránce, zavolá se page_mkwrite(). Jádro tak dostane příležitost pro dodatečný zápis alokovat buffer_heads, pokud je to potřeba, nebo vrátit chybu v případě ENOSPC nebo EDQUOT. Pokud dojde k chybě, write_begin() ji vrátí, takže změna v oblasti mapované paměti vrátí chybu (SIGSEGV). Funkce zapisující data na disk - block_write_full_page() kontroluje buffery všech stránek, ne jenom ty, které jsou v současné velikosti souboru. Dokud to probíhá, zajišťuje nová sekvence zkracování, že soubor není zkrácen. To řeší problém ztráty dat.

Patch zavádí ve struct address_space_operations nové pole new_writepage, které obsahuje novou metodu používanou k provedení writepage(). Jako nová sekvence zkracování je i toto pole dočasný hack a zmizí, až se všechny souborové systémy přizpůsobí novému standardu zapisování stránek na disk. Souborové systémy implementující novou metodu writepage musí nastavit new_writepage a zvládat soubory s dírami tak, že připraví vytváření děr ve write_begin() a dokončí ho ve write_end(). Staré chování page_mkwrite() je obnoveno v noalloc_page_mkwrite(). To při výpadku stránky nealokuje žádné bloky a označí všechny nemapované buffery ve stránce jako zpožděné [delayed], takže je zapíše block_write_full_page().

Nová funkce simple_create_hole() je analogická k ostatním funkcím simple_*; je to jednoduchý způsob, jakým vytvořit díru v souboru. Tato funkce vynuluje ty části stránek, které jsou součástí díry. Funkce je volána, kdykoliv je velikost souboru zkracována na hodnotu vyšší, než je současná velikost.

Nyní je zasílána třetí verze patche a většina námitek z předchozích verzí byla vyklizena. Vzhledem k tomu, že tento patch řeší uzavření souběhu, je pravděpodobné, že bude nakonec začleněn. Tato série nicméně závisí na nové sérii zkracování, takže musí počkat, až se tyto patche dostanou do hlavní řady. A navíc bude muset zmizet hackovitá metoda rozpoznávání nového writepage. To vyžaduje, aby všechny souborové systémy začaly novou sekvenci writepage používat.

KS2009: Výstupy z minisummitů

Velikost a záběr jádra ztěžuje diskutování záležitostí specifických pro jednotlivé subsystémy přímo na summitu, takže se stalo běžným zvykem, že pro specifická zákoutí se pořádají oddělené minisummity. Na hlavním Jaderném summitu jsou potom z těchto minisummitů prezentovány zprávy; v Tokyu byly čtyři.

Realtime

Thomas Gleixner přednesl zprávu z minisummitu, který se nedávno konal v Drážďanech. Specifické záležitosti zde zmíněné zahrnovaly škálovatelnost, velký jaderný zámek [big kernel lock] a problém s pojmenováním zámků. Linux pro běh v reálném čase mívá tendence narazit na problémy se škálovatelností dříve, než na ně narazí "běžný" linuxový systém; v tomto ohledu je určitým druhem kanárka v uhelném dole. Jedním z velkých problémů je v současnosti dcache_lock. Odstranění BKL je pro vývojáře běhu v reálném čase velkou prioritou; je to považováno za předpoklad pro začlenění zbývajícího kódu do hlavní řady. Pojmenování spinlocků bylo zmíněno, ale diskuze o tom byla odložena na úterý.

Více informací o tom, co se dělo na minisummitu stromu pro běh v reálném čase, vizte v tomto článku.

Síťování

Vývojáři síťování měli summit v Portlandu těsně před LinuxCon. Jedním z diskutovaných témat bylo systémové volání recvmmsg(), které implementuje Arnoldo Carvalho de Melo. recvmmsg() může znamenat velký výkonnostní zisk v situacích, kdy se ví, že lze očekávat několik datagramů.

Další oblast vývoje je omezení přerušení při vysílání. Rozhraní NAPI pomáhá síťovému stacku omezit režii způsobenou přerušeními při příjmu již léta, ale vysílání má také dopady na výkonnost. Zprovoznit běh s omezenými přerušeními pro odcházející pakety může být výzvou, obzvláště pokud je do systému připojen rozbitý hardware, který tuto vlastnost implementuje špatně. Síťový stack nutně potřebuje vědět, že síťový adaptér se specifickým paketem skončil, aby bylo možné uvolnit s ním spojené zdroje. Pokud hardware tuto informace správně nezpřístupní, věci mohou jít velmi rychle z kopce.

Ukazuje se, že omezení přerušení při vysílání je také důležité pro virtualizační řešení. Upozorňování na přijetí mezi hosty může být překvapivě drahé; omezení přerušení zajistí, že virtualizované síťování běží efektivněji.

Vývoj také probíhá v oblasti řízení provozu [traffic shaping] pomocí kontrolních skupin. Až bude tato práce dokončena, mělo by být možné řidit tímto mechanismem propustnost a přístup na jednotlivé porty.

Práce na síťování ve více frontách je také ve vývoji; pro některé situace (například forwarding) je nyní téměř optimální. V jiných, jako je například provoz přicházející na lokální cíl, je stále co na práci. Ted Ts'o se zeptal, jestli se někdo zabýval tím zaháčkovat se v plánovači, aby se zajistilo, že přicházející data budou směrována na správné CPU. Problém je zde nicméně to, že o tom rozhoduje síťová karta. Existují karty, které lze naprogramovat, aby směřovaly specifické pakety na správné CPU; podpora pro tuto vlastnost se v síťovém stacku zlepšuje.

Správa napájení

Len Brown prezentoval současný stav správy napájení a zprávu z minisummitu, který se konal v červenci před Linux Symposium. Cílem vývojářů správy napájení je v současnosti to, aby správa napájení byla ve výchozím nastavení na všech systémech povolena bez dopadu na výkonnost. Ohledně tohoto cíle došlo k pokroku, přidání ladícího frameworku a nové, zjednodušené API pro ovladače hodně pomohlo. Stejně tak pomohly vlastnosti ohledně kvality služby [quality-of-service] a nějaká zlepšení hardwaru od Intelu.

S ironií bylo poznamenáno, že nyní je možné uspat (a pravděpodobně probudit) systém S390.

V hardwarové vrstvě se správa napájení začíná brát na vědomí; vrstva mac80211 odnedávna bere na vědomí události uspání/probuzení.

Narozdíl od mnoha správců subsystémů Len udržuje statistiky nahlášených a opravených chyb v subsystému ACPI - a ukazuje je ostatním. Tempo hlášení chyb zůstává v čase většinou konstantní, ale počet otevřených chyb klesá. Jinými slovy vývojáři ACPI opravují chyby rychleji, než je zanášejí.

Podpora ACPI je nyní v hlavní řadě; byla dokonce dodávána předtím, než byla vydána oficiální specifikace. Ve skutečnosti se jedná o první podporu ACPI 4.0 mezi všemi operačními systémy.

Mezi nové vlastnosti v 2.6.32 patří podpora měření výkonu a tolik diskutovaný patch vynuceného zabrzdění procesoru. V 2.6.33 dojde k přepracování kódu pro hlášení chyb a objeví se podpora pro "IPMI op-region". Hotova naopak není podpora pro stav D3Hot; nikdo zatím ještě neví, jak ji použít. Někdy se objeví podpora pro vlastnost MCST, která operačnímu systému sděluje, jak velký systém může být - například kolik paměti lze nainstalovat. Je také mnoho vlastností ACPI - monitorování propustnosti pamětí, probouzecí zařízení, rozšíření pro teploty atd. - které budou implementovány, až a pokud vůbec někdo vytvoří hardware, který tyto vlastnosti bude mít.

Pracuje se na vybírání nejzajímavějších vlastností z TuxOnIce a jejich začlenění do hlavní řady. Sní se o tom, že by nakonec vývojář(i) TuxOnIce pracovali na hlavní řadě a ne mimo ní na vlastním externím stromě. Také se pracuje na výkonnosti uspávání do RAM; konkrétně probouzení zařízení asynchronně vypadá jako dobrá cesta k tomu, aby systém rychleji přešel zpět do funkčního stavu.

A nakonec probíhá hodně práce na ladění p- a c- stavů. Někteří výrobci by radši tuto funkcionalitu implementovali v BIOSu; Len a spol. by rádi předvedli, že tuto práci je lepší řídit na úrovni operačního systému.

I/O řadiče

Komunita okolo I/O řadičů je již dlouho zahanbována bohatstvím; k dispozici je několik implementací. Jak řekl Fernando Luis Vásquez Cao, který prezentoval výsledky z minisummitu I/O řadičů, který se konal těsně před Jaderným summitem, k dispozici je jich nejméně pět. Bylo by hezké snížit tento počet na jeden, který by poté mohl být začleněn do hlavní řady.

Uživatelé I/O řadičů chtějí mnoho vlastnosti včetně možnosti řídit I/O provoz na základě proporcionální váhy i maximální propustnosti. Z toho pocházejí rozdíly mezi jednotlivými implementacemi. Řadič na úrovni I/O plánovače umožňuje relativně snadno implementovat řízení podle váhy; také je relativně dobrý v tom, že dosahuje maximálního využití disku. Řadič nad úrovní virtuálního úložiště je naproti tomu lepší pro řízení maximální propustnosti; také může řídit I/O zařízení, které obchází I/O plánovač, a může poskytnout řízení, které více zohledňuje topologii.

Kromě toho kompletní kontrola bufferovaných zápisů vyžaduje spolupráci s kódem virtuální paměti. Tato kooperace umožňuje řídit poměr špinavých stránek, sledovat stránky a zajistit, aby si kód zpětného zápisu byl vědom infrastruktury řízení I/O.

Který přístup tedy na minisummitu vyhrál? Dospělo se k závěru, že bude implementován jediný řadič fungující na všech výše zmíněných úrovních. Vývojáři I/O řadičů budou spolupracovat na vytvoření nástroje, který bude pracovat jak podle BIO (vysokoúrovňově), tak podle požadavků (na úrovni I/O plánovače). Pro obě úrovně bude jediná řídící infrastruktura.

Současný plán je nejprve propojit I/O plánovač CFQ s kontrolními skupinami. Vývojáři by tuto práci rádi viděli v 2.6.33, ale Fernando si myslí, že to je příliš ambiciózní plán; 2.6.34 vypadá pravděpodobněji. Až to bude hotovo, začne se pracovat na řízení I/O na úrovních BIO a VM.

Otázka, která se objevila na konci prezentace, byla: k podobné dohodě se došlo v dubnu na Storage and Filesystems workshop; co se od té doby změnilo? Zdá se, že tentokrát jsou vývojáři odhodlanější dovést tento plán do konce. Jens Axboe poznamenal, že tentokrát si "přinesl velký klacek."

Další záležitosti se týkaly ostatních I/O plánovačů - co s lidmi, kteří CFQ nepoužívají? Dlouhodobý plán je, zdá se, omezit počet I/O plánovačů v systému. Doufá se, že nakonec zůstanou pouze plánovače CFQ a noop, nemá tedy smysl zaháčkovat I/O řadiče do ostatních I/O plánovačů.

KS2009: stav plánovače

Peter Zijlstra začal diskuzi "o stavu plánovače" poznámkou, že Con Kolivas se občas objeví s novým plánovačem a lidé začnou posílat hlášení o chybách v plánovači v hlavní řadě. Peter by byl opravdu rád, kdyby tuto část procesu bylo možné přeskočit a dostávat hlášení o problémech bez ohledu na Conovo tempo vydávání. Plánování je obtížné, požadavků je mnoho a jsou často protichůdné, ale když budou lidé posílat hlášení o chybách, nejlépe s reprodukovatelnými testy, vývojáři plánovače udělají pro opravu maximum.

V současnosti je nejzajímavější práce v oblasti plánování plánovač orientovaný na časový limit. Je mnoho typů pracovní zátěže, kde statické priority nelze dost dobře namapovat na prostor problému. Největší změna v 2.6.32 je přepracování kódu pro vyrovnávání zátěže. Mezi jinými věcmi vyrovnávání zátěže začíná brát na vědomí "kapacitu CPU" - doteď plánovač vždy předpokládal, že každý procesor je schopen odvést stejné množství práce. Je ale mnoho věcí - například správa napájení za běhu - které tento předpoklad mohou zneplatnit. Nový kód pro vyvažování zátěže se tedy pokouší pozorovat, kolik toho které CPU zvládá, a vyvodit z toho odhad kapacit, které se následně použijí při rozhodování o plánování.

Zde bylo poznamenáno, že s plánováním na NUMA systémech jsou stále spojeny problémy, které ale nebyly popsány nijak detailněji.

Diskuze se poté přesunula k benchmarkům plánovače pro zátěže desktopu. Bylo pozorováno, že vývojáři jádra mají tendence optimalizovat pro překlad jádra, což nutně nemusí být pro širší základnu uživatelů reprezentativní zátěž. Peter poznamenal, že v tomto ohledu pravděpodobně bude užitečný nástroj perf; uživatelé mohou zaznamenat chování systému při problematické zátěži, načež vývojáři mohou použít zaznamenaná data a reprodukovat jimi problém. Linus tvrdil, že u mnoha problémů s interaktivitou na desktopu není plánovač relevantní - že skutečný problém spočívá v na úrovni I/O plánovače a souborového systému. Ostatní s tím nicméně nesouhlasí a tvrdí, že v plánovači CPU stále zůstávají nějaké problémy.

Na novější CPU se vrací hyperthreading; jak se plánovač pokusí zlepšit výkonnost na systémech s HT? Problém je v tom, že proces běžící na jednom HT CPU negativně ovlivňuje výkonnost bratrského CPU. Kód pro proměnnou kapacitu zde může pomoci, ale objevila se stížnost, že tento kód je omezen jenom na to, co bylo pozorováno v minulosti. Budoucnost může být jiná, obzvlášť pokud se zátěž posune. S tím se ale nedá nic dělat; předpovídání budoucnosti je stále problematické.

Lze k lepšímu odhadování kapacity CPU použít čítače výkonnosti? Odpověď je, zdá se, negativní: čtení z čítače výkonnosti je velmi drahá operace. Snaha začlenit tyto čítače do rozhodování plánovače by výkonnost zabila.

Jako problém byla prezentována i cena za plánovač samotný, obzvláště na embedded systémech. Není nicméně jasné, jak velká část problému opravdu spočívá v plánovači a za jak velkou část může to, co se provádí při tiku časovače. Jedno z pozorování je, že nepřímé volání funkcí (používané v plánovači při volání specifických plánovacích tříd) může na některých architekturách napáchat škody. Linus řekl, že lidé, kteří na takový problém naráží, "by si měli pořídit x86 a přestat brečet," nicméně je dost pravděpodobné, že toto řešení není vhodné pro všechny. Přinejmenším pro některé architektury by mohlo dávat smysl změnit nepřímé volání funkcí na nějaký switch.

Následně se diskutovalo o problému, že některé proprietární databáze spouštějí specifická vlákna s plánovací třídou pro běh v reálném čase. Zjevně tím obcházejí problémy spojené s používáním spinlocků v uživatelském prostoru. Vývojáři se shodli na tom, že tento kód by měl používat futexy a nenasazovat svá vlastní schémata zamykání.

Tak jednoduché to ale není: Chris Mason popsal, že se snažil přesvědčit lidi od databází, aby použili futexy, a oni že to zkusili. Výsledná výkonnost byla mnohem horší a on byl "v diskuzi na hlavu poražen." Jeden problém je v tom, že futexy postrádají schopnost běhu v adaptivním cyklu [adaptive spin], díky které by běžely rychleji. Hodně stížností ale bylo také na zamykání v glibc.

Ze všech obvyklých důvodů nikdo není příliš optimistický v tom, že by bylo možné zamykání v glibc opravit. Mluví se tedy o vytvoření oddělené knihovny pro uživatelský prostor, která by problém obešla a zpřístupnila aplikacím rozumné zamykání. Mohla by to být reimplementace POSIX vláken, nebo jednodušší knihovna zaměřená na zamykací primitiva. Vytvoření takové knihovny by mohlo být složité, nicméně by to mohlo přinést výhody - například by bylo možné poskytnout uživatelskému prostoru nástroj pro ladění zámků podobný lockdep.

Komunita Samby by potřebovala UID souborového systému specifické pro jednotlivá vlákna. Jádro to umožňuje již nyní, ale glibc tuto schopnost schovává, takže ji aplikace nemohou použít. Oddělená knihovna pro vlákna/zamykání by aplikacím mohla zpřístupnit i tuto funkcionalitu.

KS2009: právní záležitosti

Právníci na Jaderném summitu často k vidění nejsou. Na setkání roku 2009 si nicméně vývojáři poslechli přednášku dvou právníků o softwarových patentech a jak se s nimi vyrovnat. Tato diskuze začala poměrně pomalu, někteří z přítomných k ní byli zjevně skeptičtí. Přidělený čas byl nakonec nicméně využit dobře; posluchači se zjevně chtěli dozvědět více o problémech představovaných softwarovými patenty a o tom, co lze udělat, aby byl Linux chráněn před nejhoršími nebezpečími.

Diskuzi vedli Karen Copenhaver, právnička Linux Foundation, a Keith Bergelt, vedoucí Open Invention Network. Prvním tématem bylo obranné zveřejňování. Softwarové patenty jsou ve Spojených Státech relativní novinka a ti, kdo patenty zkoumají, nemají k dispozici databázi dříve existujících děl [prior art], se kterou by aplikace mohli porovnávat. Výsledkem je přidělování velkého počtu patentů pro techniky, které jsou vývojářům známy už léta. Od těch, kdo patenty zkoumají, se nevyžaduje (ani toho nemusí být schopni) kompletní prohledávání literatury - tím méně prohledávání existujících zdrojových kódů - takže techniky, které nejsou v databázi patentů, jsou pro ně v podstatě neviditelné.

Obranné zveřejňování je technika, která spočívá v popsání vynálezu v té podivné podobě angličtiny, která se používá pro patenty, a publikování tohoto popisu do databáze USPTO. Publikace v této formě zakládá existující dílo, které potom ten, kdo patent zkoumá, může snadno najít. To následně může pomoci zabránit vydání patentu pro krytý vynález a chránit společnost, která ho zveřejnila, před patentovými žalobami. OIN by komunitě ráda pomohla tyto publikace vytvářet; ideálně tak, aby to bylo možné bez velkých dopadů na čas zúčastněného vývojáře.

Peter Zijlstra se zeptal: proč jsou udělovány patenty technikám, které byly popsány již v učebnicích z roku 1970? Kromě nedostatečné databáze existujících děl je důvodem velké vytížení patentových úřadů. Zmizí problém s nadcházejícím rozhodnutím Nejvyššího soudu Spojených států? Karen odpověděla, že neví o žádném patentovém právníkovi, který by si myslel, že by toto rozhodnutí opravdu něco změnilo. V budoucnosti bude těžší patenty získat, ale samo o sobě to nezajistí, že by ta obrovská hromada existujících patentů zmizela. V dlouhodobém měřítku budou možná užitečnější změny, které se v současnosti dějí na patentovém úřadě; změny týkající se toho, jak probíhá zkoumání patentů a jak jsou za to zaměstnanci odměňováni, postupem času snad kvalitu patentů zlepší.

Byla vyjádřena obava, že obranná publikace může fungovat jako potenciální návnada pro patentové trolly. Pokud někdo drží patent, který pokrývá techniky popsané v takové publikaci, pak ví, že autor publikace patent pravděpodobně porušuje. Na tuto otázku, zdá se, není dobrá odpověď. Vývojáři byli také zvědaví, jak mají poznat, jestli udělali něco, co si zaslouží vydání obranné publikace. Odpovědí zde je to, že pokud byl projekt pro vývojáře složitý, dost možná je dostatečně zajímavý na to, aby byl publikován.

Krátce došlo i na popis toho, co Open Invention Network dělá. Zdá se, že existuje živé tržiště patentů. Firmy držící patenty se je snaží přeměnit na peníze, zatímco ti, kdo jsou kvůli patentům napadáni, shánějí zbraně pro protiútoky. OIN toto patentové tržiště sleduje a pokouší se zabrat patenty, které by Linux mohly ohrožovat - nebo které by mohly ohrožovat někoho, kdo by mohl na Linux zaútočit. Takové patenty zůstávají v rezervě, aby mohly být nasazeny proti společnostem, které Linux za něco žalují.

Patentové portfolio OIN je v současnosti mocnou zbraní proti společnostem, které vytvářejí a prodávají vlastní produkty. Proti patentovým trollům, kteří jsou imunní vůči soudním příkazům a nemají nic, za co by se na ně podala protižaloba, nicméně tak užitečné nejsou. Jsou to právě trollové, kteří jsou pro Linux největší hrozbou.

Když patent existuje, je možné zkusit ho zneplatnit jeho napadením na patentovém úřadě, ale to je drahá a riskantní strategie. Pokud pokus patent zrušit selže, může ho naopak posílit; také může znehodnotit předchozí dílo, které bylo při tomto pokusu použito. Patentů je obrovské množství, z nichž mnoho nikdy nebude nijak využito; není možné zkusit je zneplatnit všechny. A nakonec - pokud o zneplatnění může vést na škody za úmyslné porušení. To všechno dává dohromady jediný závěr: frontální útok proti patentům často není nejlepší způsob.

Místo toho je možné patenty obcházet. Obcházení je samo o sobě komplikované téma a čas určený na tuto diskuzi vypršel předtím, než mohlo být diskutováno, takže stále neexistuje žádná politika ohledně toho, jestli by do hlavní řady mělo být začleňováno obcházení patentů; neoficiální politika je nicméně taková, že je to akceptovatelné pouze v případě, že to nenarušuje funkcionalitu.

Jedna z posledních otázek byla o tom, jestli existuje nebezpečí pro konkrétní vývojáře: byli nějací vývojáři žalováni za porušení patentů? Zdá se, že zatím se tak nestalo; patentoví trollové většinou míří na cíle s většími kapsami. Bylo nicméně připomenuto, že Linux Foundation pro takový případ má obranný fond; pokud by se vývojář svobodného softwaru v takové situaci ocitl, může mít k dispozici více zdrojů, než si myslí.

KS2009: Jak Google používá Linux

Pravděpodobně není žádná organizace, která by používala více Linuxových systémů než Google. Vývojová komunita jádra ale ví jenom málo o tom, jak Google Linux používá a na jaké problémy naráží. Zaměstnanec Googlu Mike Waychison navštivil Tokyo, aby pomohl situaci trochu osvětlit; výsledkem byl zajímavý pohled na to, co je potřeba k provozu Linuxu v tak extrémně náročném prostředí.

Mike posluchače hned zezačátku rozesmál: Google spravuje svůj jaderný kód pomocí Perforce; za to se Mike rovnou omluvil. Přibližně každých 17 měsíců Google změní základní bod [rebase] své práce podle současného vydání hlavní řady; následuje dlouhý boj s tím, aby všechno zase začalo fungovat. Když je to hotovo, interní vydávání "vlastností" se opakuje přibližně každých šest měsíců.

Tento způsob rozhodně není ideální; znamená to, že je Google za hlavní řadou opožděn a má tedy problém hovořit s vývojovou komunitou o svých problémech.

Na jádře pro Google pracuje kolem 30 zaměstnanců. V současnosti většinou své věci vloží do stromu a pak na ně na 18 měsíců zapomenou, což vede k značným problémům při údržbě; vývojáři často netuší, co v jejich stromě je, dokud se to nerozbije.

A je toho opravdu hodně. Google začal s jádrem 2.4.18 - opatchovali ale přes 2000 souborů a vložili 492 000 řádek kódu. Mezi jinými věcmi do tohoto jádra backportovali podporu pro 64 bitové stroje. Nakonec se přesunuli k 2.6.11, hlavně protože potřebovali podporu pro SATA. Následovalo jádro založené na 2.6.18 a nyní se pracuje na přípravě jádra založeného na 2.6.26, které by mělo být nasazeno v blízké budoucnosti. V současnosti do 2.6.26 přenášejí 1208 patchů, které vkládají téměř 300 000 řádek kódu. Přibližně 25% z toho jsou podle Mikova odhadu backporty nových vlastností.

Plánuje se toto všechno změnit; skupina vývojářů jádra z Googlu se snaží dostat do bodu, kde budou schopni lépe pracovat s lidmi od jádra. Pro správu zdrojových kódů začínají používat git a vývojáři budou své změny uchovávat ve svých vlastních stromech. Základní bod těchto stromů bude měněn podle hlavní řady každého čtvrt roku; to by, jak se doufá, mělo vývojáře motivovat k tomu, aby svůj kód udržovali spravovatelnější a více propojený s jádrem hlavní řady.

Linus se zeptal: proč tyto patche nejsou v upstreamu? Je to proto, že se za ně Google stydí, nebo jsou to tajné záležitosti, které nechce zveřejnit, nebo jde o problém interních procesů? Odpověď zněla jednoduše "ano". Část toho kódu jsou ošklivé věci, které se táhnou od jádra 2.4.18. Také jsou pochybnosti o tom, kolik z nich by bylo zbytku světa opravdu užitečné. Přibližně polovinu tohoto kódu by nicméně mělo být nakonec možné začlenit.

Kolem tří čtvrtin kódu Googlu spočívá ve změnách vnitřního jádra [core kernel]; podpora zařízení je relativně malá část celku.

Google má mnoho "bolestivých míst", které ztěžují práci s komunitou. Držet se upstreamu je těžké - prostě se pohybuje příliš rychle. Také je skutečně problém s tím, že vývojář zašle patch a následně je požádán, aby ho přepracoval způsobem, který ho mění na mnohem větší projekt. Alan Cox na tento problém reagoval jednoduchým doporučením: lidé vždycky chtějí víc, ale občas je nejlepší prostě jim říci "ne".

V oblasti plánování CPU Google zjistil, že přechod na zcela férový plánovač [completely fair scheduler] je problematický. Problematický byl natolik, že nakonec portovali starý O(1) plánovač tak, aby mohl běžet na jádře 2.6.26. Změny sémantiky sched_yield() způsobily problémy, obzvláště vzhledem k zamykání v uživatelském prostoru, které Google používá. Vlákna o vysoké prioritě mohou napáchat zmatek ve vyvažování zátěže, i když běží jenom krátce. A na vyvažování zátěže záleží: u Googlu běží nějakých 5000 vláken na systémech s 16-32 jádry.

Co se týče správy paměti, novější jádra změnila správu špinavých bitů, což vede k příliš agresivnímu zapisování na disk. Systém by snadno mohl narazit na situace, kde spousta malých I/O operací vygenerovaných kswapd zaplní fronty požadavků, kvůli čemuž ostatní zpětný zápis vyhladoví; tento konkrétní problém by měl být opraven změnami pro zpětný zápis podle BDI v 2.6.32.

Jak bylo poznamenáno výše, Google používá systémy se spoustou vláken - což obecně není neobvyklý druh práce. Jedna věc, na kterou přišli, je, že vysílání signálu velkým skupinám vláken může vést k velkému soupeření o zámek fronty běhu. Také mají problém se soupeřením o semafor mmap_sem; jeden spící čtenář může blokovat zapisovatele, což následně zablokuje ostatní čtenáře, takže se všechno zastaví. Jádro je potřeba opravit tak, aby nečekalo na I/O, když je držen tento semafor.

Google často používá zabíjení při nedostatku paměti [out-of-memory (OOM) killer], aby se napravily přetížené systémy. To ale může způsobit potíže, když na zabijáka narazí procesy držící mutexy. Mika by zajímalo, proč se jádro tak snaží místo toho, aby pokusy o alokaci paměti prostě selhávaly, když paměť dochází.

Co všechno tedy s tímto kódem v jádře Google dělá? Hodně se snaží vytěžit maximum z každého stroje, který mají, takže na každý naloží spoustu práce. Tato práce je rozdělena do tří tříd: "citlivá na latenci" [latency sensitive], která má garance ohledně krátkodobého využívání zdrojů, "produkční dávková" [production batch], která má garance pro delší časové období, a "nejlepší snaha" [best effort], která žádné garance nemá. Toto dělení na třídy je použito částečně kvůli rozdělení každého stroje na větší počet falešných "NUMA uzlů". Specifické úkoly jsou potom přiřazovány jednomu nebo více těchto uzlů. Jedna věc, kterou si Google přidává, jsou "VFS LRU pracující s NUMA" - správa virtuální paměti, která se zaměřuje na specifické numa uzly. Nick Piggin poznamenal, že pracuje na něčem podobném a že by rád viděl kód Googlu.

Pro opravdu nečinné třídy je zvláštní plánovací třída SCHED_GIDLE; pokud není k dispozici žádné CPU, úlohy v této třídě vůbec neběží. Aby se zabránilo problémům s inverzí priorit, procesům SCHED_GIDLE se dočasně zvyšuje priorita, když spí v jádře (ale ne, když jsou v uživatelském prostoru přerušeny preempcí). Síťování je řízeno HTB disciplínou fronty doplněné logikou pro řízení šířky pásma. Disky pracují s proporcionálním plánováním I/O.

Krom toho je spousta kódu, který Google používá, určena pro monitorování. Monitorují veškerou aktivitu sítě a disku, aby ji bylo možné později analyzovat. Byly přidány háčky, které umožňují spojit veškeré I/O s aplikací - včetně I/O pro asynchronní zpětný zápis. Mike se zeptal, jestli by se pro to daly použít sledovací body; odpověď je "ano", ale Google již přirozeně používá své vlastní schéma.

Mike svůj hovor zakončil několika "zajímavými problémy". Jedním z nich je, že v Googlu by rádi přikovali metadata souborového systému do paměti. Problém je zde snaha mít možnost omezit čas, který je potřeba k obsloužení požadavků na I/O. Čas potřebný k přečtení bloku z disku je jasný, ale pokud nejsou v paměti relevantní metadata, může být zapotřebí více než jedna operace disku. To věci zpomaluje. Google to momentálně obchází tak, že čte data souborů přímo z disků v uživatelském prostoru, ale toho by chtěli nechat.

Druhý problém je snížení režie systémového volání pro poskytování rad ohledně cachování (fadvise()) jádru. Zde nebylo zcela jasné, o jaký problém se přesně jedná.

Tato diskuze byla považována za jednu z těch úspěšnějších, kde se jaderná komunita hodně dozvěděla od jednoho ze svých největších zákazníků. Pokud plány Googlu orientovat se více na komunitu přinesou ovoce, výsledkem by mělo být lepší jádro pro všechny.

KS2009: Výkonnostní regrese

Výkonnostní regrese jádra jsou předmětem rostoucího zájmu. Podle některých obsahuje jádro více vlastností a je stále relativně bezchybné, ale postupem času se zpomaluje; tuto obavu vyjadřuje Linusova slavná poznámka pronesená v září na LinuxCon "Linux je přecpaný". Na Jaderném summitu se toto téma objevilo několikrát a Matthew Wilcox vedl krátkou diskuzi, kde byl tento problém diskutován.

Toto sezení bohužel nebylo možné snadno popsat, nicméně Jon se o to pokusil.

Matthew se v Intelu zabývá určitým objemem testování výkonnosti s cílem sledovat trendy v postupujícím čase. Po nějakou dobu testovali vydání RHEL, ale problém je v tom, že tato vydání jsou od sebe poměrně vzdálena, takže je obtížné sledovat problémy, které jsou nalezeny. Nyní se tedy testují -rc jádra, takže je možné rychle najít některé typy výkonnostních regresí.

Většina diskuze se týkala specifických problémů, které byly nalezeny a opraveny. Často jsou to překvapivě malé věci. Na jedné často používané cestě bylo volání kmalloc() nahrazeno voláním kzalloc() a jádro se o 1% zpomalilo. Přidání statistik disku pro jednotlivé oddíly stálo 3%. Větší změny někdy také bolí: přechod na paměťový alokátor SLUB stály 7%, nicméně se podařilo vybojovat to zpět na "pouze" 2%. A někdy je velmi těžké předpovědět, co se stane; SLQB alokátor vyvíjený mimo hlavní řadu se na starších systémech choval velmi dobře, ale poté na současných čipových sadách "zkolaboval".

Závěry z této diskuze byly poměrně vágní. Dobré benchmarky výkonnosti se těžko shání a některé z nich jsou proprietární s omezenými možnostmi diskutování výsledků. Bylo by hezké mít lepší sadu komunitních benchmarků, ale to znamená, že by je někdo musel implementovat. Také je zapotřebí mít hardware, na kterém se testuje; většinou se jedná o velmi nové a drahé vybavení. Jaderní vývojáři byli požádání, aby se na výkonnost dívali jako na vlastnost, ale dokud jejich jedinou zpětnou vazbou bude příležitostný benchmark provedený někde jinde, bude těžké se této vlastnosti věnovat pořádně.

Aktuální verze jádra: 2.6.32-rc5