Jaderné noviny - 18. 2. 2009

20. 3. 2009 | Jirka Bourek | Jaderné noviny | 3989×

Aktuální verze jádra: 2.6.29-rc5. Citáty týdne: James Bottomley, Andrew Morton, Matthew Garrett. Od probouzecích zámků ke skutečnému řešení. Jak se poměřit s ksize(). Rozhovor: návrat stromu realtime preempce.

Obsah

• Aktuální verze jádra: 2.6.29-rc5
• Citáty týdne: James Bottomley, Andrew Morton, Matthew Garrett
• Od probouzecích zámků ke skutečnému řešení
• Jak se poměřit s ksize()
• Rozhovor: návrat stromu realtime preempce

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

Současné vývojové jádro 2.6 je stále 2.6.29-rc5 vydané 13. února. Obsahuje nějaké aktualizace ovladačů a spoustu oprav. Tak hurá a pořádně ho otestujte, protože já hodlám strávit třídenní víkend opilý na pláži. Protože někdo to udělat musí. Detaily vizte v kompletním changelogu.

Současné stabilní jádro 2.6 je 2.6.28.6 vydané (společně s 2.6.27.18) 17. února. Obě obsahují dlouhý seznam oprav různých problémů.

Před nimi byly 12. února vydány 2.6.28.5 a 2.6.27.16. 2.6.27.17 bylo urychleně vydáno těsně poté s opravou problému "okamžitého oops" na některých laptopech.

Citáty týdne: James Bottomley, Andrew Morton, Matthew Garrett

Například iSCSI: vykašlalo se na svůj počáteční slib, do protokolu přetáhlo spoustu zbytečného síťování a nakonec je tak velké, že se nevejde do firmware disku (čímž se ztrácí možnost jednoduše se přichytit na síť a nahradit úložnou infrastrukturu). Pomalu upadalo, dokud se neobjevila virtualizace. Nyní jsou všechny způsoby, jak do virtuálních strojů dostat úložné zařízení, tak otřesné a složité, že iSCSI vyhrává (jestliže je alternativou Frankensteinovo monstrum, Grendelova matka najednou vypadá jako partnerka mnohem atraktivněji).

-- James Bottomley

Momentálně tu mám nedodělky za posledních několik dní, omlouvám se. Pravděpodobně za to může déšť - opravdu bych měl počítač přemístit do domu.

-- Andrew Morton

Když je logické rozšíření reakce na problém "přidat konfigurační volbu téměř ke všem ovladačům", je potřeba se zamyslet znovu.

-- Matthew Garrett

Od probouzecích zámků ke skutečnému řešení

Článek o probouzecích zámcích z minulého týdne popsal rozhraní pro blokování uspávání, které pochází z projektu Android, a nepřátelskou reakci, kterou toto rozhraní obdrželo. Od té doby diskuze pokračovala ve dvou oddělených vláknech. Jaderní vývojáři, stejně jako všichni technici, řeší problémy, takže diskuze se rychle přesunula od kritiky probouzecích zámků k hledání akceptovatelného řešení. V době psaní tohoto článku toto řešení neexistuje, ale o problému jsme se dozvěděli nějaké zajímavé věci.

Donutit správu napájení fungovat v Linuxu byl dlouhý, vleklý proces, který z větší části znamenal opravovat ovladače zařízení jeden po druhém. Mnoho práce bylo věnováno tomu, aby se zajistilo, že CPU zůstane v klidovém stavu tak dlouho, jak je to jen možné. Jedním z důvodů, proč vývojáři jádra považují rozhraní probouzecích zámků za tak nepříjemné, je to, že vývojáři Androidu zvolili ke správě napájení jiný přístup. Místo toho, aby se snažili neustále minimalizovat spotřebu energie, se kód Androidu snaží zařízení uspat, kdykoliv je to možné. K tomuto přístupu je několik důvodů, k jednomu z nich se dostaneme níže.

Začneme nicméně velmi jednoduchým důvodem, proč Android používá řešení "uspat celý svět": protože může. Hardware, na kterém Android běží, byl podobně jako mnoho embedded systémů (a na rozdíl od většiny systémů založených na x86) navržen tak, aby se uspával a probouzel rychle. Vývojáři Androidu proto nevidí důvod, proč to dělat jinak. To ale vede ke komentářům, jako je tento od Matthewa Garretta:

Vaše řešení problému zčásti není přijímáno proto, že vypínání nepoužívaného hardwaru je spojeno s embedded systémy, které mají velmi malé latence při probouzení. Můžete si dovolit řešit problém zadáním explicitního stavu uspání. V mobilním světě x86 tuto možnost nemáme - pro uživatele je to jednoduše příliš pomalé a rušivé. V důsledku toho nás mnohem více zajímá hardwarová správa napájení, která nevyžaduje uspání celého systému.

Řešení, které se zaměří na vypnutí tolika nepoužívaného hardwaru, kolik je možné, bez ohledu na stav systému, je přínosné jak pro svět x86, tak pro svět embedded zařízení, takže si myslím, že to je poměrně silný argument pro to, že jde o lepší řešení než to, které vyžaduje explicitní změnu stavu systému.

Matthew také poznamenává, že je možné vyřešit problém správy napájení bez úplného uspání systému; jako příklad úspěšné implementace dává tablety Nokia, které při správě napájení používají jemnější dělení.

Zdá se, že je jasné, že přístup s kompletním uspáváním nezmizí; některý hardware je navržen tak, aby takto fungoval nejlépe, takže Linux potřebuje pro tento režim práce podporu. Proto se mluvilo o tom, jak probouzecí zámky navrhnout takovým způsobem, který lépe zapadne do jádra jako celku. Na straně jádra byly nějaké dohady o tom, jestli je vůbec mechanismus probouzecích zámků zapotřebí; ovladače již teď mohou zabránit jádru v pokusu uspat systém. Nicméně je opodstatněné tvrdit, že je lepší, když bude jádro vědět, že se nemůže uspat, aniž by se kvůli tomu muselo dotazovat všech ovladačů.

Jedno řešení, které navrhl Matthew, by byl jednoduchý pár funkcí: inhibit_suspend() a uninhibit_suspend(). Na produkčních systémech by to manipulovalo s atomickým čítačem; když by čítač obsahoval nulu, systém by bylo možné uspat. Tyto funkce by mohly přebírat strukturu device jako parametr; ladící verze by potom mohly zjišťovat, které zařízení v danou dobu blokuje uspání. Ekvivalent v uživatelském souboru by mohl být soubor jako /dev/inhibit_suspend; dokud bude mít alespoň jeden proces tento soubor otevřený, systém bude dál běžet. Shrnuto to vypadá jako jednoduché API, které nemá mnoho z problémů, jež jsou k vidění v kódu probouzecích zámků.

Na straně Androidu bylo několik stížností, ale nejproblematičtějším bodem jsou, zdá se, časové limity. API probouzecích zámků implementuje automatický časový limit, který způsobí, že se "zámek" po zadaném čase uvolní. Pro existenci těchto časových limitů je několik důvodů:

• Vzhledem k tomu, že ne všechny ovladače používají API probouzecích zámků, jsou časové limity zapotřebí k tomu, aby se zabránilo v uspání systému, když tyto ovladače běží. Navrženým řešením této záležitosti je změnit všechny ovladače, které potřebují, aby systém běžel. Jakmile bude do jádra začleněno akceptovatelné API, ovladače je možné změnit podle potřeby.

• Pokud proces držící probouzecí zámek neočekávaně zemře, časový limit udrží systém v provozu do doby, než kód watchdogu tento proces restartuje. Problém je zde v tom, že časové limity do jádra vkládají obnovující politiku a příliš se nestarají o to, jestli je toto fungování správné. Místo toho bylo navrženo, aby byla politika "zabránění uspání" v uživatelském prostoru uzavřena do odděleného démona, který by mohl rozhodovat o tom, jestli držet systém vzhůru.

• Aplikace v uživatelském prostoru mohou být špatně napsané a neumožnit uspání systému.

Poslední možnost je také používána jako argument pro přístup ke správě napájení s kompletním uspáváním. I když se špatně chovající aplikace dostane do smyčky a odmítne se ukončit, systém se nakonec stejně uspí, aby šetřil baterii. To je argument, který se mnoha jaderným vývojářům moc nelíbí, protože říkají, že místo programování jádra, aby se chránilo proti špatným programům, by bylo lepší opravit ty programy. Arjan van de Ven upozorňuje na to, že od vzniku PowerTop byla opravena většina problémů v open-source aplikacích.

V tomto prostoru je nicméně těžší všechny tyto problémy ošetřit. Brian Swetland situaci popisuje takto:

1. výrobce vydá zařízení
2. výrobce se uvolí k tomu povolit instalaci libovolných aplikací třetích stran bez potřeby otřesných certifikačních programů, které vyžadují, aby autoři složitě překonávali překážky, čekali celou věčnost na schválení atd.
3. uživatelé se radují a instalují všemožné druhy programů
4. některé programy jsou napsané špatně a to má vliv na životnost baterie
5. uživatelé si stěžují na životnost baterie u výrobce

Matthew také problém potvrzuje:

Pamatujme na to, že Android je otevřené tržiště vytvořené k tomu, aby se zalíbilo programátorům v Javě - uživatelé si odtud budou stahovat kód a potom obviní platformu, když se životnost baterie přiblíží k nule. Řekl bych, že "nemůžeme věřit tomu, že uživatelský prostor není blbý" je platná obava.

Jde o skutečný problém, ale stále není jasné, jestli jsou vhodné pokusy opravit takový problém v jádře - nebo jestli budou tyto pokusy úspěšné. Ben Herrenschmidt nabízí jiné řešení: démona, který by sledoval chování aplikací a varoval uživatele, že se zdá, že se daná aplikace chová špatně. To by aspoň dalo uživateli na srozuměnou, kde problém skutečně spočívá. To ovšem není žádná náhrada za skutečné řešení: spouštění open-source aplikací na telefonu tak, aby mohl špatné chování v případě potřeby opravit uživatel.

Platforma Androidu je nicméně explicitně navržena k tomu, aby podporovala proprietární aplikace. Může se ukázat, že je schopna tyto aplikace přitáhnout tak, jak se to standardnímu linuxovému desktopu nikdy docela nepovedlo. Bude tedy potřeba najít nějaké řešení problému správy paměti u špatně napsaných aplikací. Vývojářům Androidu se jako řešení líbí probouzecí zámky, ale také se zdá, že mají zájem na tom spolupracovat s komunitou na nalezení globálněji akceptovatelného řešení. Jak takové řešení bude vypadat však nebude jasné bez mnoha dalších diskuzí.

Jak se poměřit s ksize()

Jedna z méně známých funkcí podporovaných kódem jaderné správy paměti je ksize(); když je jí předán ukazatel na objekt alokovaný pomocí kmalloc(), ksize() vrátí velikost tohoto objektu. Tato funkce většinou není zapotřebí; ti, kdo volali kmalloc(), obvykle vědí, co alokovali. Může být ale užitečná v situacích, kdy funkce potřebuje znát velikost objektu a nemá tuto informaci po ruce. Jak se tak stává, ksize() má další potenciální uživatele, ale také jsou zde nějaké nástrahy.

Uživatelé ksize() jsou v hlavní řadě ojedinělí. Do roku 2008 byl hlavním uživatelem kód architektury nommu, o kterém se zjistilo, že používá ksize() v mnoha situacích, kde to není vhodné. Výsledkem bylo pročištění kódu nommu a zrušení exportování funkce ksize() ve snaze zabránit tomu, aby se tato situace opakovala.

Štěstí vydrželo donedávna; jádro 2.6.29-rc5 obsahuje patch crypto kódu, který používá ksize(), aby se ujistil, že jsou ze struktur crypto_tfm zcela vymazána citlivá data předtím, než je struktura vrácena systému. Nepřítomnost exportu ksize() způsobila, že kód selhal, pokud byl přeložen jako modul, takže Kirill Shutemov zaslal patch, který ji exportuje. Tady začala být diskuze zajímavá.

Proti obnovení exportu ksize() se objevil odpor; zdá se, že největším problémem je to, že tuto funkci je snadné použít nesprávně. Volání ksize() je v pořádku jedině tehdy, když se mu předává ukazatel získaný od kmalloc(), ale programátoři jsou často v pokušení používat ho i na jiné typy objektů. Situaci nepomáhá ani fakt, že paměťové alokátory SLAB a SLUB bez problému zafungují, pokud je ksize() předán jakýkoliv slab-alokovaný objekt. Pro SLOB alokátor to ale neplatí. Vysvětlení této situace vedlo ke stížnostem od Andrewa Mortona:

OK. Tohle je opravdu špatně, že ano? Lidé napíší kód, který bude spokojeně fungovat pod slab a slub, jenom aby spadl té malé části lidem, kteří ho (mnohem později) otestují se slobem?

[...]

To je v háji. Největší chyba, kterou jsem kdy udělal. Pracujeme dostatečně na tom, abychom odstranili jednu z těchto implementací sl?b? Pomohlo by, kdybych jich pár náhodně vymazal?

Zatím nebyla vymazána ani jedna z implementací; místo toho se zdá, že SLQB alokátor míří k začlenění do 2.6.30. Nápad omezit přístup ke ksize() se také daleko nedostal; export této funkce byl v 2.6.29-rc5 obnoven. Jádro je koneckonců plné nebezpečných funkcí - taková je povaha jaderného kódu - a není možné bránit se před všemi chybami, které by mohl vývojář jádra udělat. Jak řekl Matt Mackall, jde pouze o další základní chybu:

A to -je- kategorická chyba. Fakt, že kmalloc je implementován nad kmem_cache_alloc, je implementační detail, na který by volající neměli spoléhat. Neměli by volat kfree() na kmem_cache_alloc objekty (i když by to náhodou mohlo fungovat), ani by neměli volat ksize().

Existuje i další potenciální důvod, proč ponechat tuto funkci k dispozici: ksize() může ukázat, že má další využití kromě toho, že vývojáři díky ní nemusí sledovat velikost alokovaných objektů. Jedno veřejně známé tajemství o kmalloc() je to, že má tendence alokovat objekty, které jsou větší, než volající požaduje. Rychlý pohled na /proc/slabinfo (se správným paměťovým alokátorem) ukáže mnoho cachí se jmény jako kmalloc-256. Pokaždé, když je voláno kmalloc, se požadovaná velikost zaokrouhluje nahoru k nejbližší velikosti slabu a je vrácen objekt o této velikosti. (Opět - toto platí pro SLAB a SLUB alokátory; SLOB je zvláštní případ.)

Toto zaokrouhlování nahoru vede k jednoduššímu a rychlejšímu alokátoru, ale tyto zisky jsou získány za cenu plýtvání částí paměti. To je jeden z důvodů, proč má smysl vytvořit dedikovaný slab pro často alokované objekty. Je zde ale jedna zajímavá alokace, která musí používat kmalloc() z důvodů DMA kompatibility: alokace SKB (buffer pro paket ze sítě).

SKB má typicky velikost, která odpovídá maximální velikosti přenesených dat pro cílové síťové rozhraní. Ve světě, kterému vládne Ethernet, bývá tato velikost 1500 bytů. Objekt o velikosti 1500 bytů požadovaný od kmalloc() typicky vede na alokaci 2048 bytového kusu paměti; to znamená významné množství vyplýtvané paměti. Síťoví vývojáři nicméně skutečně potřebují, aby SKB buffer nepřekračoval hranice stránky, takže obecně není způsob, jak se tomuto plýtvání vyhnout.

Může ale existovat způsob, jak ho využít. Síťová vrstva příležitostně potřebuje navíc uložit nějaká s paketem spojená data; například se zdá, že IPSec velmi pravděpodobně takovou situaci vytvoří. Síťová vrstva by mohla pro tato data alokovat další paměť, ale také může použít krealloc(), který by rozšířil aktuálně alokovaný buffer, což by ale obojí zpomalilo velmi vyladěný kód síťování. Mnohem hezčí je využít nějaké místo navíc, které se povaluje po okolí. S bufferem od kmalloc() přitom toto místo může být k dispozici. A způsob, jakým to zjistit, je samozřejmě použít ksize(). A to je přesně to, co mají vývojáři síťování v úmyslu.

Ne všichni jsou přesvědčeni, že tento trik stojí za potíže. Někteří mají pocit, že by extra prostor měl být alokován explicitně, pokud bude později zapotřebí. Další by rádi viděli nějaké benchmarky, které ukazují, jaký zisk tato technika přináší ve skutečném světě. Jaderní vývojáři ale většinou ocení hezký trik, takže ksize() bude připraveno, pokud by se tento druh kódu v budoucnosti dostal do hlavní řady.

Rozhovor: návrat stromu realtime preempce

Projekt realtime preempce je dlouhotrvající snaha poskytnout deterministickou dobu odezvy ve všeobecném jádře. Během posledních pár let byla velká část této práce začleněna do hlavní řady jádra a mnoho výrobců dodává komerční produkty na ní založené. Během posledního roku se nicméně pokrok směrem k začlenění zbytku realtime práce do hlavní řady zpomalil.

11. února se realtime vývojáři Thomas Gleixner a Ingo Molnár znovu objevili s oznámením nového stromu realtime preempce a obnovené snahy o vývoj. Jon Corbet, autor tohoto článku, je požádal, jestli by zodpověděli několik otázek o této práci; jejich odpověď šla hodně za rámec povinností, dočtete se tedy velmi detailní informace o tom, kde strom realtime preempce stojí a co se pravděpodobně stane v blízké budoucnosti.

LWN: Oznámení 2.6.29-rc4-rt1 poznamenává, že se vracíte z rok a půl dlouhé dovolené. Proč jste se RT patchům nevěnovali tak dlouho; celou dobu jste se povalovali na pláži? :)

Thomas: Strávili jsme skvělý čas u x86 laguny, místě extrémních kontrastů mezi starožitnostmi a moderním uměním. :)

Ale vážně, podcenili jsme množství práce, které bylo zapotřebí, abychom vyladili sjednocenou architekturu x86. Není si na co stěžovat; rozhodně to byla snaha, která stála za to, a kdybych ji měl udělat znova, neváhal bych déle, než zlomek sekundy.

Ingo: Jo, povalování na pláži skoro dva roky jsme si oba zasloužili. Potkali jsme tam Linuse a byla tam spousta srandy, plážové koktejly zadarmo, hezké západy slunce a táboráky. [Mimochodem, všechno placeno těmi hodnými lidmi z Microsoftu - tihle lidé rozhodně ví, jak potěšit linuxového hackera! ;-)]

LWN: Co vás tedy tentokrát přitáhlo zpět k práci na realtime?

Thomas: Nuda a nostalgie :) Ve skutečnosti jsem od té doby, co jsme začali pracovat na údržbě x86, nikdy neztratil přehled o práci na reálném čase. Moje snahy byly nicméně omezeny na řešení problémů a zajištění toho, aby byly patche udržovány v použitelném stavu. Momentálně mám pocit, že je potřeba opět vložit do preempt-rt více vývojové práce, aby upstream zůstal viditelný a aby se pokračovalo v začleňování zbývajících částí.

Nejdůležitějším důvodem k návratu byla nicméně výzva v Příručce nabručeného redaktora pro rok 2009: "Sada realtime patchů bude koncem roku z větší části začleněna..."

Ingo: Když jsme se před více než rokem a půl vydali do země x86, fronta rt patchů byla velká hromada patchů, které měnily stovky kritických jaderných souborů a zaváděly/dotýkaly se tisíců nových řádků kódu. Přetočme o rok a půl dopředu a fronta těchto patchů je nyní obrovská hromada patchů, které mění téměř tisíc kritických jaderných souborů a zavádí/dotýká se dvaceti až třiceti tisíc řádků kódu. Proto jsme se shodli, že i když projekt roste hezky, je použitelný a lidé ho mají rádi, růst je namířen poněkud mimo a v této konkrétní oblasti je potřeba nějaká pomoc.

Původně to začalo jako náš myšlenkový experiment: kolik času a snahy by zabralo portovat většinu stabilního rt patche (.26-rc15) na strom .29-tip a přimět ho k tomu, aby nabootoval? Ukázalo se, že myšlenkové experimenty nám moc nejdou (stejně jako nám moc nejde udržovat malé fronty patchů), takže jsme dohady museli vyřešit programováním. Portování fronty byla zábava, dokonce nabootovala po několika tuctu oprav a výsledkem je vydání .29-rt1.

Zkušenosti ze správy stromu x86 po tak dlouhou dobu a provádění mnoha složitých konceptuálních modernizací v této oblasti nám při portování fronty patchů -rt k nejnovějšímu jádru hlavní řady také pomohly.

Většina kódu, kterého se dotýká, a většina konfliktů, které se objevily, nám byly značně povědomé, jako by tyto změny v upstreamu prošly skrz naše stromy ;-)

(Určitě se to ale nevyrovnalo zážitkům z pláže, takže stále pokukujeme po možnosti vrátit se na několik měsíců na Hawai.)

LWN: Jak dobře v současnosti funguje realtime kód? Co si myslíte, že jsou největší zbývající záležitosti, kterým je třeba se věnovat?

Thomas: Realtime kód se dostal do poměrně stabilního stavu. Verze založené na 2.6.24/26 mohou rozhodně být považovány za připravené k nasazení. Strávil jsem u těchto verzí spoustu času řešením velkého množství detailů, aby byly stabilní. Stále potřebujeme refaktorovat spoustu patchů a hledat pro některé změny spojené s reálným časem taková řešení, která budou akceptovatelná do hlavní řady jádra.

Ingo: Co se mě týče, tak spoustu otázek typu "potřebujeme -rt v hlavní řadě?" zodpovědělo vylepšení točících se mutexů [spinning mutex]. Před nimi jsme měli hodně poměrně patologických zátěžových scénářů, kde byla výkonnost -rt daleko za hlavní řadou. S nimi jsou poměrně srovnatelné.

Dělení patchů a jejich kvalita se také zlepšily a fronta, kterou jsme portovali, se v podstatě přeloží a nabootuje v téměř každém bodu rozdělení [bisection point], takže je to poměrně použitelné. Velká část patchů vypadla z fronty .26, protože se mezitím dostaly do hlavní řady: sledovací patche, patche plánovače, patche dynamického tiku/časovačů s vysokým rozlišením atd.

Celkově to vypadá mnohem méně děsivě než před rokem a půl - i když celková velikost je stále značná, takže je ještě tuna práce, kterou je potřeba udělat.

LWN: Jaké jsou v současnosti vaše myšlenky ohledně začlenění do hlavní řady?

Thomas: Nejprve bychom chtěli integrovat -rt patche do našeho -tip gitového repozitáře, což zjednoduší udržování tempa s probíhajícím vývojem hlavní řady. Další kroky jsou postupně refaktorovat patche buď přepsáním, nebo lépe přetažením práce, která proběhla v Stevensově stromě git-rt, rozdělit je na části, které jsou připraveny k začlenění, a začlenit je krok za krokem.

Ingo: Podle mě je klíčová myšlenka opět udržovat -rt strom 'před vývojovou křivkou upstreamu', rozdělit části, které jsou připraveny k začlenění a udělat z něj hranici linuxového výzkumu a vývoje. Se základem 2.6.26 to bylo poměrně složité, se základem částečného 2.6.30 (což strom -tip ve skutečnosti je) je mnohem více před křivkou a je mnohem více příležitostí začlenit kousky -rt do upstreamu, kdekoliv je v něm náhodná aktivita, ke které lze připojit s -rt spojená pročištění a změny. Přeskočili jsme téměř 4 kompletní vydání jádra, což -rt přesouvá přes rok vývoje upstreamu - a udržuje ho na špičce.

Dalším faktorem je, že mnoho z nejčastějších přispěvatelů do -rt také přispívá do -tip, takže je zde silná součinnost.

Strom -tip také podstupuje vážnou snahu o automatickou stabilizaci a "produktizaci", takže je to dobrá základna pro vývoj a pro praktické denní používání. Například zde nebyla hlášena žádná selhání překladu proti .29-rt1 a většina z ostatních selhání, která byla ohlášena, byly menší chyby, které byly rychle opraveny. Jednu z věcí, které jsme se naučili během posledního roku a půl, bylo, jak udržet strom stabilní v divokém, nebezpečně vypadajícím toku modifikací.

YMMV

LWN: Thomas mi jednou říkal o schématu, ve kterém by se rtmutexy patchovaly do/z běžícího jádra během bootu, což by distributorům umožnilo dodávat jediné jádro, které by mohlo běžet buď v realtimovém, nebo "normáním" režimu. Je to stále něco, na čem pracujete?

Thomas: Momentálně na tom nepracujeme, ale je to stále na seznamu věcí, které je potřeba prozkoumat.

Ingo: Stále to zní jako zajímavá vlastnost, ale je poměrně těžké to zvládnout. Před několika lety jsme mívali něco, co tomu bylo poměrně blízké: přepínač, který za běhu přepnul kód rtmutexů zpět na točící se [spinning] kód. Bylo to křehké, těžko udržovatelné, takže jsme to nakonec vyhodili.

Ideální by bylo něco takového dělat ne během bootu, ale za běhu - pomocí mechanismu stop-machine-run [zastavit běh stroje] nebo tak. (Možná s rozšířením o hibernační bity, které by každou úlohu donutily přejít do uživatelského režimu, takže by byly všechny zámky v systému uvolněny.)

Je skutečně obtížné to implementovat a rozhodně to není pro slabé povahy.

LWN: Kód RT-preempce se zdá být jednou z největších výjimek z pravidla "nejprve do upstreamu", které nabádá k tomu, aby byl kód nejprve začleněn do hlavní řady předtím, než je dodán zákazníkům. Jak to fungovalo v tomto případě? Jsou případy, kdy je dobré dodávat kód mimo hlavní řadu jádro po tak dlouhou dobu?

Thomas: Je to výjimka, která byla akceptovatelná jenom díky tomu, že preempt-rt nezavádí nová API pro uživatelský prostor. Pouze mění chování běhu jádra tak, aby bylo více deterministické.

Všechny změny, které jsou spojeny s API do uživatelského prostoru (např. PI futexy) byly začleněny do hlavní řady předtím, než byly dodány zákazníkům v preempt-rt a všechny opravy chyb a vylepšení kódu hlavní řady byly okamžitě zaslány do upstreamu. Preempt-rt nikdy nebyl oddělený projekt, který se nestará o hlavní řadu.

Když jsme začali s preempt-rt, byla na straně zákazníků obrovská poptávka - jak u podniků, tak u embedded systémů - po jádře s vyřešeným realtime během. Přístupy RTAI, RT-Linux a Xenomai s duálním jádrem nikdy neměly šanci dostat se do hlavní řady jádra a obsluha prostředí s duálním jádrem nikdy nebyla jednoduchý úkol. S preempt-rt prostě přepnete jádro s běžným prostředím uživatelského prostoru hlavní řady a voila, vaše aplikace se chová, jak byste očekávali - většinou :) Prostředí s duálním jádrem vyžaduje odlišné knihovny, odlišná API a stejnou binárku nelze provozovat na jádře s vypnutým -rt. Ladění realtimových aplikací založených na preempt-rt je úplně stejné, jako ladění nerealtimových aplikací.

I když jsme nikdy neměli pochyby, že je možné změnit Linux na realtimový OS, od samého začátku bylo jasné, že to bude dlouhá cesta, než budou všechny kousíčky a kousky začleněny. První otázka, na kterou se mě Ingo zeptal, když jsem ho v prvních dnech preempt-rt kontaktoval, byla: "Jsi si jistý, že se při práci na preempt-rt chceš dotknout každé části jádra?" Tato otázka byla naprosto legitimní; v prvních dnech preempt-rt jsme se skutečně dotkli každé části jádra vzhledem k problémům, které byly většinou spojeny se zamykáním a preempcí. Tyto opravy byly začleněny do upstreamu a obzvláště v oblasti zamykání jsme v hlavní řadě dosáhli značných zlepšení díky ladění zámků, přechodem na mutexy atd. a obecně lepšího povědomí o sémantice zamykání a preempce.

preempt-rt byl vždycky skvělou živnou půdou pro významné změny jádra, zatím byla poměrně velká část vývoje preempt-rt začleněna do hlavní řady: PI-futexy, časovače s vysokým rozlišením ... doufám, že v tom vytrváme a brzy nabídneme zajímavější technologické změny, které původně vznikly při snaze vytvořit preempt-rt.

Ingo: Preempt-rt v jádře převrací plánování, správu zámků a kód obsluhy přerušení, takže nebyla žádná realistická cesta, jak to všechno začlenit do upstreamu bez nějaké zpětné vazby z praxe. Také je unikátní to, že potřebujete všechny tyto změny, abyste dosáhli nového chování jádra - k samotnému konceptu -rt není postupný přístup. To tak trochu tvoří hlavu-22: do upstreamu to nedostanete bez nasazení v praxi a k nasazení v praxi nedojde, dokud to nedostanete do upstreamu.

Deterministické zpracování je významná oblast, taková, která v minulosti nikdy nebyla pokryta mainstreamovým jádrem. Je to možná poslední významná technologická oblast, kterou běžné jádro z upstreamu neřeší, a není divu, že je v tomto postavení z konceptuálně složitých důvodů.

Ve zkratce: všechny jednoduché technologie jsou již v upstreamu ;-)

I tak jsme nicméně striktně všechna ABI do uživatelského prostoru nejprve začleňovali do upstreamu: hlavně PI-futexy. Zbytek -rt je "jenom" nová volba v jádře, která magicky přepne chování jádra do deterministického režimu.

LWN: Kde je nejlepší počáteční bod pro vývojáře, který by k této snaze chtěl přispět?

Thomas: Na realtime patchích není nic zvláštního. Prostě obvyklý vývoj jádra: stáhněte patche, aplikujte je, spusťte na svém stroji a testujte. Pokud se objeví problémy, poskytněte hlášení o chybě nebo je zkuste opravit sami a pošlete patche. Pročtěte kód a začněte vytvářet vylepšení, pročištění ...

Ingo: Kromě návrhu "vyzkoušejte ho sami, sledujte diskuze a jděte tam, kam vás srdce táhne" je zde pár náhodných oblastí, které potřebují více pozornosti:

• Odstranění velkého jaderného zámku [Big Kernel Lock]. Pro -rt je to kritické. Stále máme větev tip:core/kill-the-BKL a pokud má někdo zájem, bylo by hezké v této snaze pokračovat. Mnoho hezkých pomozte-zlikvidovat-VJZ patchů se nedávno dostalo do jádra (jako například patche ve funkci open zařízení), takže jsme vcelku v dobré pozici k závěrečnému úderu kladiva.
  (Právě jsem dodělal (čerstvé!) obnovení [refresh] a začlenění pro řešení konfliktu tohoto stromu s v2.6.29-rc5. Lidé, kteří mají zájem, ho mohou najít na:

  git pull \
    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git \
    core/kill-the-BKL

  Varování: možná se to ani nepřeloží.)

• Podívejte se na Stevův git-rt strom, dělte ho a postupně začleňujte kousky. Velká část věcí byla pročištěna, takže by bylo dobré tuto práci zachovat.

• Měření latence a nástroje. Zkuste sledovač latencí, sledovač grafů funkcí a ftrace obecně. Pokuste se najít zpoždění aplikací způsobené jádrem (nebo samotnou aplikací) a zamyslete se nad tím, jestli by bylo možné jaderné zabudované nástroje vylepšit.

• Vyzkoušejte Thomasovu utilitu cyclictest a pokuste se vysledovat a vylepšit ty nejhorší latence. Hezkým cílem by bylo zatlačit nejhorší latence na současných PC pod 10 mikrosekund. Momentálně jsme s .29-rt1 na 13 mikrosekundách s hackem, který dělí zpracování IRQ časovače do vláken, takže si myslím, že je možné se pod 10 mikrosekund dostat.

• A samozřejmě: prostě se pokuste vylepšit jádro hlavní řady - z definice to vylepší i -rt jádro ;-)

Ale jako vždycky, jděte po své vlastní cestě. Nezávislé, kritické myšlení je mnohem cennější než chování držet-se-davu. (Tedy v případě, že to končí vytvářením patchů, nikoliv flamewarů ;-))

A každopádně, začněte v malém a hledejte zpětnou vazbu v lkml, brzy a často. Být dobrým a užitečným vývojářem jádra není vlastnost, ale proces, a aby procesy dobře prosperovaly, vždy potřebují čas, mnoho postupných kroků a smyčku zpětné vazby.

Mnohokrát děkuji Thomasovi i Ingovi za to, že si našli čas na (detailní!) zodpovězení tohoto dlouhého seznamu otázek.

       

Komentáře

[stativ]

Nemá se psát Hlava 22?

[teni]

Když už, tak Hlava XXII, ne? Ale v článku je to zmíněno jako ustálený pojem označující nějakou absurdní skutečnost, nikoli jako název knihy, čili tam bych myslel, že si to každý může psát, jak je mu libo.

[stativ]

Aha.

[geebranz]

Real solution

storageshedsmemphis.com