Jaderné noviny – 27. 10. 2011: Realtime minisummit v Praze

7. 11. 2011 | Luboš Doležel | Jaderné noviny | 3085×

Aktuální verze jádra: 3.1. Citáty týdne: Linus Torvalds, Neil Brown. Realtime minisummit 2011: Per-CPU data; Softwarová přerušení; Přesun do upstreamu; Budoucnost.

Obsah

• Aktuální verze jádra: 3.1
• Citáty týdne: Linus Torvalds, Neil Brown
• Realtime minisummit 2011
  • Per-CPU data
  • Softwarová přerušení
  • Přesun do upstreamu
  • Budoucnost

Aktuální verze jádra: 3.1

Vyšlo jádro 3.1, a to Linusovo rukou dne 24. října. Hlavními funkcemi v tomto tak trochu opožděném vydání zahrnují vylepšenou správu paměti Xenu, vylepšení sledování procesů (příkaz PTRACE_SEIZE), rozšíření lseek() pro snazší hledání děr v souborech, podpora architektury OpenRISC a ještě více.

V době psaní tohoto textu bylo do hlavní řady přetaženo nějakých 4400 patchů pro verzi 3.2. Mezi stromy, které byly zatím přetaženy, patří síťování, USB, staging a bezpečnost; úplné shrnutí začleňovacího okna se objeví v příštích Jaderných novinách.

Stabilní vydání: 25. října vyšlo jádro 3.0.8 s obvyklou hromadou důležitých oprav.

Citáty týdne: Linus Torvalds, Neil Brown

Z čeho mám větší obavy než z jaderného summitu, je to, že vývojový cyklus verze 3.1 se příliš protáhl, takže mám trochu obavy, že začleňovací okno 3.2 bude chaotičtější než obvykle, protože se bude začleňovat víc věcí. Ale to s problémy KS nesouvisí a mám také za to, že extra čas na vývoj byl do značné míry vyrušen ztrátou produktivity kvůli výpadku k.org.

-- Linus Torvalds

Neměl jsem v plánu to udělat... ale pak jsem to udělal. Myslím si, že kódování je někdy trochu jako čokoláda.

-- Neil Brown

Realtime minisummit 2011

Minisummit realtime Linuxu proběhl 22. října v Praze během třetího dne 13. Realtime Linux Workshopu. Součástí letošního shromáždění byla relativně nestrukturovaná diskuze, která se nedá moc čistě sepsat. Pokusili jsme se zde shrnout nejdůležitější témata, doplněná o materiály z některých přednášek.

Per-CPU data

Jednou z největších výzev pro sadu patchů pro realtime preempci bylo už od začátku zacházení s per-CPU daty. Vývojáři orientovaní na propustnost mají per-CPU proměnné v oblibě; usnadňují přístup k datům bez zámků a zlepšují škálovatelnost kódu. Ale práce s per-CPU daty obvykle vyžaduje vypnutí preempce, což je přímo proti tomu, o co se snaží sada patchů realtime preempce. Je to klasická ukázka toho, jak mohou být vysoká propustnost a nízká latence protichůdnými cíli.

Realtime patch tradičně řešil per-CPU data tak, že na ně dal zámek a pracoval s nimi jako s každým jiným sdíleným prostředkem. API get_cpu_var() tento režim podporuje docela dobře. Nedávno toto API ale bylo odstrčeno novou sadou funkcí s názvy jako this_cpu_read() a this_cpu_write(). Předností těchto funkcí je rychlost, zejména na architektuře x86, kde většina operací znamená jen jedinou instrukci. Ale toto nové API způsobilo jisté obtíže, obzvláště (ale ne výhradně) pro lidi z realtime party.

Prvním problémem je to, že toto API nemá žádný vestavěný mechanismus zamykání; dokonce ani nezakazuje preempci. Takže hodnota vrácená z this_cpu_read nemusí odpovídat CPU, na kterém volající vlákno běží v době, kdy něco dělá s hodnotou, kterou čte. Bez nějakého vnějšího zákazu preempce může sled this_cpu_read() následovaného this_cpu_write zapsat zpátky hodnotu na jiném CPU, než kde byla hodnota přečtena, což poškodí výslednou strukturu dat; tento typ problému byl už párkrát zaznamenán.

Větším problém je ale to, že toto API žádným způsobem neindikuje, kde se v kódu nachází kritická sekce týkající se per-CPU dat. Takže není žádný způsob, jak přidat extra ochranu pro realtime operace a není žádný způsob, jak přidat nějakou infrastrukturu pro ladění, aby se ověřilo, že je API používáno korektně. Na mailing listu se kolem těchto funkcí objevily dosti ostré diskuze, ale jednoduchým argumentem je to, že věci urychlují, takže se proti nim těžko argumentuje. API this_cpu představuje skutečný přínos; Ingo Molnar poznamenal, že API jako takové není problémem – je to jen nekompletní řešení.

Ať už je nebo není nekompletní, počet míst, odkud se toto API volá, s každým vydáním jádra roste o stovky, takže je třeba s tím něco udělat. Mnoho času bylo stráveno diskutováním o tom, jak tyto funkce pojmenovat, protože je to takto matoucí. Co „toto CPU – this CPU“ znamená v situaci, kdy může volající vlákno být kdykoliv přemigrováno? Může se objevit snaha změnit tato jména, aby se tím odrazovalo od nesprávného užití API, ale to jednoznačně není dlouhodobé řešení.

Prvním krokem může být přidat do rozhraní nějakou instrumentaci, která by dokázala najít chybné užívání. Když už nic jiného, tak alespoň skutečný důkaz přítomnosti chyb ospravedlní změny, které bude potřeba udělat. Hovořilo se o vytvoření „lokálního zámku“, který by byl použit k ohraničení per-CPU kritických sekcí, zakázání migrace (a pravděpodobně preempce) v těchto sekcí a na realtime k prostému uzamčení. Takové rozhraní by, snad kromě splnění cílů všech lidí, umožnilo za pomoci kontroloru zámků ověřit, zda jsou per-CPU data správně užívána.

Vývojáři realtime mezitím nedávno přišli s novým obecným přístupem ke správě per-CPU dat. Namísto zakazování preempce během práce s takovými daty prostě jen zakážou migraci mezi procesory. Pokud (a toto je takové větší „pokud“) jsou per-CPU data korektně chráněna zámkem, zákaz migrace by měl postačit k tomu, aby si procesy přestaly lézt do zelí, zatímco by se zachovala možnost toho, aby procesy s vysokou prioritou přerušily [preempt] procesy s nižší prioritou, když to bude třeba.

Ze zákazu migrace pramení obavy, že by se procesy mohly zaseknout a došlo by k dlouhým latencím, i když by byla k dispozici volná CPU. Pokud proces s nízkou prioritou zakáže migraci a pak dojde k preempci, nemůže být přesunut na volný procesor. Takže tento proces by prostě čekal, dokud nedokončí proces, který jej přerušil, nebo dokud nebude sám přemigrován. Pracovalo se na vystižení tohoto problému; Paul McKenney chvíli hovořil o práci, kterou v této oblasti odvedl. V současnosti není jasné, o jak velký problém doopravdy jde, ale někteří vývojáři mají skutečně obavy, jaký vliv může tato technika mít na některou zátěž.

Softwarová přerušení

Už dlouhou dobu sada realtime patchů oddělovala obsluhu softwarových přerušení („softirq“) do odděleného vlákna, což jej učinilo přerušitelným [preemptable] jako všechno ostatní. Nedávné patche toto oddělení ale odstranily, a to z několika důvodů: aby patche byly blíže hlavní řadě a aby nedocházelo k brzdění zpracování síťových věcí. Pohyb dat v síťové vrstvě značně závisí na softirq; přesunutí této práce do odděleného vlákna může přidat latenci na nežádoucím místě. Ale pro počáteční oddělení byl dobrý důvod: softwarová přerušení mohou sama o sobě způsobovat latenci. Proto se hovořilo o tom, že by se oddělení částečně vrátilo. Většina softirq by mohla běžet v odděleném vlákně, ale síťová softirq by možná mohla nadále běžet jako „pravá“ softwarová přerušení. To není řešení, které by všechny potěšilo, ale krátkodobě by to věci zlepšilo.

Vypadá to, že na dlouhodobém řešení se lidé shodnou: softwarová přerušení prostě musí kompletně zmizet. Softirq mohou být povětšinou nahrazena vlákennou obsluhou přerušení [threaded interrupt handlers]; a jak to Thomas Gleixner popsal, API ovladačů NPAPI v síťové vrstvě je ve skutečnosti jen levná náhražka obsluhy IRQ ve vláknech. Diskutuje se o přesunutí vlákenné obsluhy i v subsystému úložišť; to zjevně představuje naději, že se zjednoduší komplexní kód obnovy po chybě v SCSI. Nicméně nejde o triviální změnu ani v úložištích, ani v síťování; než se to udělá, dlouho to potrvá. Mezitím se do realtime patchů asi vrátí částečně odloučená obsluha softirq.

Zajímavým problémem spojeným s obsluhou softirq je četný výskyt operací „trylock“. Existuje řada míst, kde se kód pokusí získat zámek; pokud tento pokus selže, obsluha IRQ se zastaví s představou, že se to zkusí znovu při příštím běhu softirq. Pokud ale obsluha běží jako vlákno, je zde velká šance, že půjde o vlákno s nejvyšší prioritou, takže to bude spuštěno znovu okamžitě. Obsluha softirq zacyklená tímto způsobem může zabránit naplánování vlákna, které drží kýžený zámek, což vede k livelocku. Tento problém už byl několikrát zpozorován na skutečných systémech; pro opravu může být nutné restrukturovat dotčený kód.

Přesun do upstreamu

Proběhla dlouhá debata o tom, jak vývojáři realtime plánují dostat většinu nebo celý patch do upstreamu. Je totiž mimo strom docela dlouho – původní patch preempt-rt byl ohlášen téměř přesně před sedmi lety. Během té doby se velké objemy kódu přesunuly z realtime stromu do hlavní řady, ale stále je tu nějakých 300 patchů, jež jsou nadále mimo hlavní řadu. Thomas už několikrát podotkl, že tyto patche spravuje už dost dlouho a nechce, ani neplánuje to dělat navždy.

Většina z toho, co je v realtime stromu, vypadá, že by se do upstreamu dostat mohla, jen by snad bylo potřeba trochu pročištění. Nyní je ve frontě kolem 75 patchů, které směřují do začleňovacího okna 3.2 a ještě více by se toho mohlo připravit pro 3.3 nebo 3.4. Aktuálním cílem je během této doby začlenit co nejvíc kódu, to by mohlo značně omezit velikost realtime sady patchů, což by usnadnilo údržbu.

Je tu několik problémových oblastí. Získávání náhodnosti je v realtime stromu zakázáno; naplňování zdroje entropie totiž způsobuje nežádoucí latenci. Vypadá to, že přispívání entropií v jádře upadá; není jisté, jestli je údržba softwarového zdroje účelná, když se v procesorech objevují hardwarové generátory entropie. Je stále řada míst, kde jsou přerušení zakázaná, pravděpodobně to není potřeba; oprava tohoto si vyžádá auditování kódu a pochopení, proč jsou přerušení vůbec zakazována. Relayfs má problémy samo o sobě, ale má to jen jednoho uživatele ve stromu; prozatím by to asi jen bylo zakázáno pro realtime. Rozhraní stop_machine() je vnímáno jako problémové a po většinu času asi jako zbytečné.

A tak dále. Řada účastníků odešla z tohoto sezení se seznamem patchů k opravě a zaslání do upstreamu; s trochou štěstí se velikost realtime patche mimo jádro znatelně zmenší.

Budoucnost

Jakmile bude současný realtime patch začleněn, bude práce hotová? V minulosti bylo zmenšování patche těžké kvůli tomu, že vývojáři neustále přicházeli s novými věcmi. Nyní to však vypadá, že na horizontu není mnoho novinek. V blízké budoucnosti se očekává jen několik významných přídavků:

• Deadline plánování. Tento patch je ve stavu, který „není až tak špatný“, ale pozornost vývojáře byla odvedena k novým věcem. Vypadá to, že práce na deadline plánovači může být převzata novým vývojářem a práce budou pokračovat.
• Izolace CPU – schopnost běžet na jednom nebo více procesorech bez tikání hodin nebo jiné režie. Fredéric Weisbecker pokračuje v práci na těchto patchích, ale zbývá hodně práce a není to až tak urgentní, aby byly hned začleněny. Toto je vnímáno jako dlouhodobý projekt.

Kdysi dávno bylo zavedení deterministické odezvy do obecného operačního systému vnímáno jako nemožný účel: výsledné jádro by nikomu nefungovalo správně. Nicméně zatímco někteří lidé říkali, že vývojáři pracující na realtime preempci prostě ještě musí zapracovat, už tohoto cíle povětšinou dosáhli. Práce na realtime nemusí být nikdy „hotová“ – stejně jako linuxové jádro jako celek není nikdy hotové – ale tento projekt vypadá, že dosáhl většiny svých cílů. Váš redaktor se ponaučil, aby nedělal předpovědi, kdy bude všechno začleněno; postačí říct, že vývojáři sami vypadají odhodlaně k tomu, aby to bylo hotové spíš dřív než později. Takže i když tu s námi možná vždycky bude realtime sada patchů mimo strom, je tu šance, že se v příštích vývojových cyklech značně zcvrkne.

       

Komentáře

[whata]

Hm, docela zajímavá komplikace.

Možná by stačilo něco ala load/store exclusive jako mají některé RISC procesory.

cpu_read by označil current_thread značkou a cpu_write by si značku zkontroloval, suspend threadu by značku vypínal, případně v samotném cpu_write posunul kontext. "Aplikační" část by si pak musela hlídat, zda se write povedl a případně celý read/write opakovat, což je sice trochu komplikace, ale pořád v rámci spolehlivosti asi použitelnější než přístup zcela bez kontroly.