Jaderné noviny - 30. 6. 2016: Virtuálně mapované zásobníky podruhé

10. 7. 2016 | Redakce | Jaderné noviny | 2635×

Stav vydání jádra. Citát týdne: Tom Herbert. Shrnutí Summitu na Glungezeru. WireGuard. Virtuálně mapované zásobníky 2: thread_info vrací úder.

Stav vydání jádra

Současný vývojový kernel nese označení 4.7-rc5, vydán byl 26. června. Linus řekl: „Myslím, že se věci uklidňují, i když to podle dvou třetin commitů, které přišly od pátečního rána, moc nevypadá – moje pátky jsou většinou velmi rušné. Ale když se dívám na čísla, jsme zhruba tam, kde normálně s rc vydáními býváme.“

Stabilní aktualizace: 4.6.3, 4.4.14 a 3.14.73 byly vydány 24. června. Kromě jiného obsahují důležitou bezpečnostní opravu.

Citát týdne

Není žádné „jádro jedna“, je mnoho různých klientských jader, v Internetu je mnoho konfigurací, mnoho implementací TCP. Některé jsou bídně navržené, roky pozadu i jinak zoufale nebezpečné. Také jsou lidé, kteří stále používají Windows 95, proboha! Nemůžeme jádrům prostě věřit, že dělají, co dělat mají. Také to od nás nikdo nevyžaduje, v žádném internetovém standardu nenajdete požadavek na implementaci TCP v jádře. Stejné je to u middleboxů a firewallů, existuje spousta implementací, řada z nich nedodržuje standardy a problémy s aktualizací software/firmware představují pro Internet možnou katastrofu. Není to od nás vyžadováno a nikdy nemůžeme předpokládat, že naše pakety půjdou přes dostatečně robustní firewall.

Sečteno a podtrženo: Pokud vyvíjíte aplikaci v Internetu, která je kritická pro vaše podnikání, nemůžete předpokládat, že operační systémy nebo sítě poskytnou dostatečné zabezpečení; musíte vzít zodpovědnost za svou aplikaci do vlastních rukou. TOU je krok správným směrem.

-Tom Herbert

Shrnutí Glungezer realtime summitu

Daniel Wagner se podělil o shrnutí z realtime summitu, který se nedávno konal na odlehlém místě v Alpách. „Christoph [Hellwig] a já jsme se rozhodli, že zorganizujeme malou konferenci na horách. Díky Christophově znalosti okolí Innsbrucku jsme vybrali chatu na Glungezeru. Nachází se téměř na vrcholu, kam se nedá dojet autem ani lanovkou. John Kacur vyslovil podezření, že Christoph chtěl skrytě podpořit fyzičku real-time vývojářů tím, že je nechá pochodovat skrze rakouské Alpy. Jak se ukázalo, měl pravdu.“

WireGuard: nový VPN tunel

Jason Donenfeld oznámil dostupnost „WireGuard“ pro linuxové jádro. „WireGuard je velmi jednoduchá a přitom rychlá a moderní VPN, která používá nejmodernější šifrování. Jejím cílem je být rychlejší, jednodušší, lehčí a použitelnější než IPSec, a to bez bolestí hlavy. Současně je cílem být mnohem výkonnější než OpenVPN.“ Kód je v raném stádiu a komunita jej předtím nikdy neviděla, dokonce se ani neobjevil jako patch. Takže možná bude ještě trvat, než se dostane do hlavního vydání. Zatím je možné kód a další informace najít na wireguard.io.

Celý článek na LWN.

Virtuálně mapované zásobníky 2: thread_info vrací úder

V minulém dílu jste se mohli dočíst o sadě patchů Andyho Lutomirského, která přesunovala jaderné zásobníky do rozsahu vmalloc(). To má spoustu výhod, mezi nimi také eliminaci některých alokací paměti vyššího řádu, vylepšení bezpečnosti a lepší diagnostický výstup při přetečení zásobníku. Jenže je tu jeden drobný háček, a sice 1,5 µs navíc při vytváření nového procesu – cena, se kterou se Linus nebyl ochoten smířit. První pokus o řešení narazil na obskurní datovou strukturu v jádře, ale nakonec se díky tomu povedlo podstatně pročistit část jádra, která se stará o informace o procesech.

Za výkonnostní regresí stojí využití vmalloc() k alokaci jaderných zásobníků; vmalloc() představuje poměrně nákladný způsob, jak alokovat paměť, a nedostalo se mu stejné pozornosti při optimalizaci, jako například slab alokátorům. Jedním z návrhů bylo kešovat několik jaderných zásobníků, což by umožnilo rychlé opětovné využití ještě teplých zásobníků po ukončení procesu. Věřilo se, že když budou odstraněna volání vmalloc(), kód obecně zrychlí.

Zbytečná cache

Andy se dal do realizace této myšlenky a referoval odrazující výsledek: „Implementoval jsem cache pro každé CPU, a je to k ničemu.“ Problém, stručně řečeno, spočívá v tom, že zdroje procesu (včetně jaderného zásobníku) nejsou uklizeny bezprostředně po ukončení procesu. Místo toho se mechanismus RCU (read-copy-update) postará o to, aby na tyto zdroje před uvolněním nezůstaly žádné odkazy. Takže (1) uvolnění jaderného zásobníku se zpozdí až do konce dalšího cyklu RCU (grace period); (2) zdroje všech procesů, které skončily během tohoto cyklu, budou uvolněny naráz. Tím pádem bude cache jaderných zásobníků téměř neustále prázdná, potom se najednou zaplní velkým počtem uvolněných zásobníků, jenže většina z nich se tam nevejde, a proto bude prostě uvolněna. Jinými slovy, četnost cache hit bude blízká nule – zvláště při zátěži bohaté na vytváření nových procesů.

Teoreticky by jaderný zásobník po skončení procesu neměl být potřeba, takže by se mohlo zdát, že by k uvolnění zásobníku mohlo dojít okamžitě, a to i když je zapotřebí zachovat ostatní datové struktury. Problém je v tom, že základní informace, které si jádro o procesech udržuje, se nacházejí na dvou různých místech:

• Velká struktura task_struct se nachází v <linux/sched.h>. Tato struktura, která je (až na znepokojivé množství bloků #ifdef) nezávislá na architektuře, obsahuje většinu informací, které jádro potřebuje o běžícím procesu vědět.
• Malá struktura thread_info, jejíž podoba závisí na architektuře.

Struktura task_struct se nachází na haldě – jako většina ostatních datových struktur jádra. Avšak struktura thread_info pobývá ve spodní části jaderného zásobníku, čímž znemožňuje opětovné využití tohoto zásobníku, dokud na ni něco může odkazovat. Toho času Linus usiloval o změny, které by umožnily rychlé uvolnění struktury thread_info, zatímco struktura task_struct by přetrvávala, leč brzy se ukázalo, že tudy cesta k jednoduchému řešení nevede. K některým informacím v thread_info, zvláště se to týká pole příznaků (flags), může být přistupováno vcelku nepředvídatelně, tudíž tyto informace musí zůstat dostupné, dokud má jádro jakékoli informace o přidružených procesech.

Existence těchto dvou struktur je v podstatě historický artefakt. V počátcích Linuxu existovala pouze task_struct a nacházela se na jaderném zásobníku. Jenže časem zásobník přerostla, ačkoliv její umístění na jaderném zásobníku mělo velkou výhodu: strukturu bylo snadné nalézt zamaskováním některých bitů z ukazatele na zásobník, tzn. k udržování její polohy nebylo potřeba ztrácet vzácné místo v registrech. V případě některých často používaných polí šlo o výhodu, o kterou jaderní vývojáři nechtěli přijít. Takže když došlo k přesunu task_struct z jaderného zásobníku, hrstka jejích důležitých částí zůstala v nově vytvořené struktuře thread_info. Výsledné řešení o dvou strukturách se používá i v současných jádrech, ovšem do budoucna tomu tak být nemusí.

Jak se zbavit thread_info

Jádro vcelku nedávno přešlo na ukládání různých typů často potřebných informací do proměnných specifických pro dílčí CPU. Plánovač některé zásadní informace o aktuálně běžících procesech ukládá do oblasti vyhrazené dílčím CPU. Ukazuje se, že to je rychlejší než přístup na dno jaderného zásobníku. Tím pádem se zmenšil objem užitečných dat v thread_info, a tak je nasnadě otázka: nemohli bychom tu strukturu odstranit úplně? Nejedná se dokonce ani o novou otázku. Přesun struktury pryč ze zásobníku byl jedním z Andyho cílů od samého počátku. Ovšem problematika výkonu dodává tomuto problému na naléhavosti.

Linus rychle přišel na to, že někteří uživatelé thread_info vlastně nepotřebují, a to dokonce aniž by byly nutné další změny. Typické použití spočívá v nalezení struktury task_struct, leč ukazatel na ni je obvykle již k dispozici. Linus tyto případy vyřešil a výsledek připravil pro vydání 4.7-rc5. Tento typ změny se možná nedá považovat za opravu chyby, pro něž je pozdní cyklus běžně určen, ale Linus dal jasně najevo, že změny považuje za přijatelné: „Toto jsou přesně ty ‚ryze historické důvody pro špatnou volací konvenci‘ a souhlasím s tím ve fázi rc vydání, abych to lidem, kteří si s nimi budou hrát, zjednodušil.“

Posunul práce dále, a to tak, že bylo možné (poněkud redukovanou) strukturu thread_info odsunout ze zásobníku a zahrnout ji do task_struct. Dostal se až do stavu, kdy šlo upravené jádro zavést na testovacím systému. Pak se věci chopil Andy a změny integroval do své větší řady patchů.

V době psaní tohoto článku byla řada patchů ve čtvrté revizi. Mnoho polí thread_info je přesunuto do task_struct, přičemž je také upravován kód, který k těmto polím přistupuje. Nakonec se do task_struct přesune i samotná struktura thread_info, která už obsahuje pouze pole příznaků. To vyžaduje řadu změn nízkoúrovňového kódu jednotlivých architektur, takže momentálně se změny dotýkají pouze architektury x86. Vypadá to, že další architektury budou následovat. I bez ostatních prací představuje eliminace samostatných struktur thread_info užitečný úklid a vylepšení zabezpečení.

S ohledem na skutečný cíl sady patchů (přesun jaderných zásobníků do rozsahu vmalloc()) odstranění struktury thread_info umožní uvolnění jaderného zásobníku, jakmile skončí příslušný proces – bez potřeby cyklu RCU. To zase umožní přidat malé cache pro dílčí CPU, které udrží až dva volné jaderné zásobníky. Díky této cache se podle Andyho stane z 1,5µs výkonnostní regrese 0,5-1µs nárůst výkonu.

Takže v této fázi má Andy řadu patchů, které zjednodušují část ústředního kódu jádra, poskytují okamžitou detekci přetečení jaderných zásobníků, poskytují lepší diagnostiku, když už k přetečení dojde, vylepšují bezpečnost jádra a dokonce i zrychlují jeho běh. Není tedy překvapením, že už je těžké najít další námitky. Jednou zbývající otázkou může být, kdy tento kód začlenit, a odpovědí se zdá být začleňovací okno 4.8. Dá se říct, že protože jde o fundamentální změny a nepochybně se objeví ještě jedna nebo dvě nepříjemnosti, jedná se o agresivní přístup. Na jednom překvapení se ostatně v době psaní článku pracovalo. Nicméně vývojový cyklus 4.8 by měl poskytnout dostatek času pro práci na takových překvapeních a ve finále půjde o výsledek, který bude stát za to.

       

Komentáře

[pc2005]

Linus rychle přišel na to, že někteří uživatelé thread_info vlastně nepotřebují, a to dokonce aniž by byly nutné další změny. Typické použití spočívá v nalezení struktury task_struct, leč ukazatel na ni je obvykle již k dispozici.

No nevím, tohle se tuším na arch/microblaze řešilo jako globální proměnná (ukazatel) na aktuálně běžící task a byla sranda to správně vyměnit s přepínáním úlohy v assembleru (například i při vyjímce paměti a nebo přerušení).

Akorát bude problém rychle přiřadit stack neběžící úloze k té struktuře (prohledávání nějakého seznamu, řekl bych).