OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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 se pro specifická zákoutí pořádají oddělené minisummity. Na hlavním Jaderném summitu jsou potom z těchto minisummitů prezentovány zprávy; v Tokiu byly čtyři.
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 hlavní den summitu.
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.
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 tyto 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é řídit 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, jak se zaháčkovat v plánovači, aby se zajistilo, že budou přicházející data směrována na správné CPU. Problém je zde ale 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.
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í.
Na rozdí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 ni 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.
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: 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čů.
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, u kterých nelze statické priority 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 je každý procesor 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, záporná: Č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í však 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.
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 ale nakonec 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 se 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 – pokus o zneplatnění může vést k napadení 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í.
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štívil Tokio, 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 ze začá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, opakuje se interní vydávání „vlastností“ 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 64bitové 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ávka“ [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.
Google má pro rok 2010 mnoho důležitých cílů; patří mezi ně:
Velký zájem o limity CPU; ty jsou určeny k tomu, aby byla úlohám citlivým na latenci přiřazena priorita, ale aby se zároveň těmto úlohám zabránilo systém zcela ovládnout.
Plánování CPU s ohledem na RPC; to zahrnuje zkoumání příchozího RPC provozu, aby se zjistilo, který proces se kvůli němu vzbudí a jak důležité to probuzení je.
S tím spojené je zpožděné plánování. Pro většinu vláken není latence tak důležitá. Jádro se je ale snaží spustit okamžitě poté, co přijde RPC zpráva; tyto zprávy nebývají mezi CPU rozprostřeny rovnoměrně, což vede k vážným problémům s vyvažováním zátěže. Vlákna tedy lze označit ke zpožděnému plánování; když dorazí probuzení, nejsou do fronty běžících vložena okamžitě. Místo toho čekají na další globální operaci vyvažování zátěže a teprve po ní se skutečně rozběhnou.
Vkládání prázdných cyklů: Správa napájení při vysoké propustnosti, aby bylo možné stroje provozovat na hranici roztavení – ale ne za ní.
Lepší řadiče paměti jsou na seznamu také, a to včetně čítání jaderného využívání paměti.
„Offline paměť“. Mike poznamenal, že je stále těžší koupit paměť, která opravdu funguje, obzvláště pokud má být levná. Je tedy potřeba odložit vadné stránky na stranu. Práce na HWPOISON by této oblasti mohla pomoci.
Potřebují dynamické obrovské stránky, které lze sestavit a zase rozebrat podle potřeby.
Co se týče síťování, potřebují vylepšit podporu pro škálování na straně příjemce – směrovat příchozí provoz do specifických front. Potřebují počítat s časem pro softwarová přerušení a přiřadit ho k jednotlivým úlohám – zpracování síťového provozu může často zahrnovat velká množství zpracování softirq. Pracují na lepším zvládání přetížení; algoritmy, se kterými přišli, nejsou „bezpečné pro internet“, i když v datovém centru fungují dobře. A „krokování TCP“ zpomaluje odchozí provoz, aby nedošlo k přetížení switchů.
Co se ukládání týče, mají velký zájem na omezení režie blokové vrstvy, aby stíhala pracovat s vysokorychlostními flash zařízeními. Používání flash v blokové vrstvě ke zrychlování disků je na seznamu také. Dívají se po překladové vrstvě pro flash v jádře, ale bylo navrženo, že tuto logiku by bylo lepší řešit přímo v souborovém systému.
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.
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ál 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ě.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
1.12.2009 16:01
CIJOML | skóre: 58
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz