Jaderné noviny – 2. 6. 2017: Vstříc neblokujícímu asynchronnímu I/O

24. 6. 2017 | Redakce | Jaderné noviny | 3812×

Stav vydání jádra. Mechanismus pro zachytávání upcallů jádra. Citáty týdne: Daniel Vetter, Casey Schaufler, Michael Kerrisk. Vstříc neblokujícímu asynchronnímu I/O.

Stav vydání jádra

Současné vývojové jádro je 4.12-rc3, vydané 28. května. Abychom citovali Linuse: „Hele, pořád to vypadá dobře a rc3 ani není moc velké. Doufám, že nás nečeká žádné překvapení, ale zatím to vypadá na příjemně klidný vývojový cyklus, velikosti začleňovacího okna navzdory.“

Stabilní aktualizace: 4.11.3, 4.9.30, 4.4.70 a 3.18.55 byly vydány 25. května.

Mechanismus pro zachytávání upcallů jádra

Nedávný článek Kontejnery jako jaderné objekty se věnoval pokusu o přidání formálního konceptu „kontejner“ do jádra, částečně jako způsob, jak zajistit běh jaderných upcallů (volání z jádra do programu v uživatelském prostoru) ve správných jmenných prostorech. Nyní je David Howells zpět s jiným přístupem: způsobem, jak by mohl proces démona zachytávat a spravovat upcally s určitým klíčem.

Konkrétně systémové volání keyctl() je vylepšeno o příkaz KEYCTL_SERVICE_CREATE, který vrací speciální popisovač souboru. Následující volání mohou přidávat „filtry“ popisující upcally, které mají být zachyceny. Ty jsou popsány jménem a skupinou příznaků označujících množinu relevantních jmenných prostorů. Pokud se jmenné prostory volajícího programu shodují s těmi procesu, který upcall vytváří, bude programu povoleno zpracovat dané volání. Podrobnější popis toho, jak to funguje, najdete v příspěvku s patchem.

Citáty týdne

Být jedinečná sněhová vločka ve velké komunitě, jakou ta okolo jádra je, je občas nezbytné, protože když dělají všichni totéž, celá komunita se nic nového nenaučí.

—Daniel Vetter

V praxi jsou whitelisty sestavovány tak, že na začátku je na nich všechno a postupně se odmazávají položky, dokud věci nepřestanou pracovat, potom jsou příslušné položky vráceny zpět. Whitelisty jsou teoreticky skvělé, ale je těžké je sestavit a v reálném světě také udržovat.

—Casey Schaufler

Souhlasím s tím, že se jedná o zvláštní scénář. Ovšem programátoři uživatelského prostoru přečíslují jaderné vývojáře 10 000 ku 1 a časem přijdou na všechny možné způsoby, jak API kreativně využít, pokud se jim „bude hodit.“

—Michael Kerrisk (díky Dimitriji Safonovi)

Vstříc neblokujícímu asynchronnímu I/O

Linuxová vrstva asynchronního I/O (AIO) mívá hodně kritiků a málo zastánců, ale většina lidí alespoň očekává, že bude skutečně asynchronní. Ve skutečnosti může být operace AIO blokující v jádře z vícero důvodů, což vede k tomu, že je AIO obtížné použít v situacích, kdy si volající vlákno skutečně nemůže dovolit blokovat. Přetrvávající sada patchů, která by měla situaci zlepšit, se blíží svému dokončení, ale jde spíše o krok správným směrem než o skutečně řešení problému.

K provedení AIO musí program nastavit kontext I/O pomocí io_setup(), vyplnit jednu nebo více struktur iocb popisujících operace, které se mají provést, potom tyto struktury odeslat pomocí io_submit(). Volání io_getevents() se dá použít ke zjištění stavu nevyřízených I/O operacích – a volitelně také počkání na ně. Všechna tato systémová volání, s výjimkou posledního, by měla být neblokující. Ve skutečnosti je to složitější. Přidělení paměti nebo zabrání zámku může způsobit blokování libovolnou operací AIO, a to dříve než dojde k zahájení přenosu dat. Dokonce i v nejlepším případě (I/O přímo do/z souboru) může samotná operace blokovat na více místech.

Sada patchů nečekajícího AIO Goldwyna Rodriguese se snaží tuto situaci vylepšit hned několika způsoby. Nečiní AIO asynchronnějším, ale vede k selhání AIO operací s chybami EAGAIN namísto blokování v řadě situací. Pokud je program na podobné chyby připravený, může se aktivně pokusit předložit I/O v hlavním vlákně. Pak se bude muset pouze uchýlit do samostatného zadávacího vlákna v případech, kdy by operace blokovala.

Pokud je program navržen, aby používal nečekající AIO, musí to dát najevo nastavením nového příznaku IOCB_RW_FLAG_NOWAIT ve struktuře iocb. Tato struktura má pole (aio_flags), která má obsahovat pouze tyto typy příznaků, ale je v tom háček: jádro aktuálně v tomto poli nekontroluje neznámé příznaky. To znemožňuje přidání nového příznaku, protože volající program nemůže nikdy vědět, zda jádro, na kterém běží, tento příznak podporuje či nikoli. Naštěstí tato struktura obsahuje několik rezervovaných polí, která v současných jádrech jsou kontrolována. Pole dříve známé jako aio_reserved1 je v této sadě patchů změněno na aio_rw_flags a používáno pro nový příznak.

Jedním z míst, kde může I/O požadavek blokovat, je operace, která spustí operaci zpětného zápisu. V takovém případě bude požadavek zdržen až do dokončení zpětného zápisu. Toto čekání se projeví na začátku procesu podání požadavku, konkrétně k němu může dojít před dokončením io_submit() a jeho vrácením. Nastavení příznaku IOCB_RW_FLAG_NOWAIT způsobí, že podání požadavku v tomto případě selže s EAGAIN.

Dalším běžným místem blokování je zadání I/O požadavku na blokové úrovni: ten může být pozastaven, protože příslušné blokové zařízení je zaneprázdněné. Možnost, jak se tomu vyhnout, zahrnuje vytvoření nového příznaku REQ_NOWAIT, který je možné nastavit ve struktuře BIO, která se používá k popisu požadavků na blokové I/O. Pokud je tento příznak přítomen, I/O požadavek opět místo blokování čekáním na blokové zařízení selže s chybou EAGAIN.

Podpora je nutná také na úrovni souborového systému, každý souborový systém má svá vlastní místa, kde může vykonání blokovat cestu k zadání požadavku. Sada patchů obsahuje podporu Btrfs, ext4 a XFS. V každém případě situace, jako je neschopnost získat zámek na příslušném inode, způsobí selhání požadavku.

Všechny tyto práce mohou AIO vylepšit, ale pouze pro omezený počet případů užití. Zlepšuje například pouze přímé I/O. I/O s vyrovnávací pamětí (buffered I/O), které bylo vždy ve vrstvě AIO spíše občanem druhé kategorie, se nemění – je příliš mnoho míst, kde může dojít k blokování, a není síla vyřešit je všechna. Obdobně neexistuje podpora síťových souborových systémů nebo souborových systémů na MD a LVM oddílech — ačkoliv Rodrigues plánuje někdy v budoucnu některá z těchto míst časem zaplnit.

Jinými slovy se zdá, že AIO zůstane užitečným jen pro těch několik aplikací, které provádějí I/O přímo nad soubory. V minulosti došlo k řadě pokusů o zlepšení situace, včetně fibrilů, threadletů, sysletů, acall a reimplementace AIO založené na jaderných vláknech, provedené původním autorem AIO. Ani jeden z těchto pokusů ovšem nikdy nedosáhl stavu, kdy by bylo zvažováno jeho začlenění do hlavního repozitáře. Existuje příliš mnoho choulostivých detailů, které je třeba vyřešit, než bude možné implementovat kompletní řešení, a zatím nikdo neshledal tento úkol natolik důležitým, aby ospravedlnil značnou práci, kterou je třeba vynaložit na řešení tohoto problému. Takže jádro se asi bude i nadále plazit kupředu s inkrementálními vylepšeními AIO.

       

Komentáře