Portál AbcLinuxu, 25. dubna 2024 06:56
Stav vydání jádra. Kroah-Hartman: Stav Meltdown a Spectre v jádře Linux. Citáty týdne: Larry McVoy, Willy Tarreau, Thomas Gleixner, David Miller a Linus Torvalds. Nové jaderné rozhraní pro dotazování.
Současné vývojové jádro je 4.15-rc7, vydané 7. ledna. „OK, byl to zajímavý týden a teď už všichni vědí, proč jsme začleňovali všechny ty divné patche izolace tabulek stránek na x86, aniž bychom postupovali podle všech těch obvyklých pravidel pro postup vydání. Ale samotná rc7 je ve skutečnosti celkem v klidu.“
Stabilní aktualizace: 4.14.12, 4.9.75 a 4.4.110 byly vydány 5. ledna, 10. ledna je následovaly aktualizace 4.14.13, 4.9.76 a 4.4.111. Všechny tyto aktualizace obsahují opravy oprav meltdown/spectre, takže kdo provozuje stabilní jadra, se nejspíš bude chtít držet nejnovějších verzí.
Tady jsou novinky od Grega Kroah-Hartmana ohledně odpovědi jádra na Meltdown a Spectre. „Pokud právě spoléháte na jiné jádro než 4.4, 4.9 nebo 4.14 a nemáte distribuční podporu, máte smůlu. Absence patchů řešících problém Meltdown je v porovnání se stovkami dalších známých zranitelností a chyb, které vaše jádro momentálně obsahuje, naprosto zanedbatelná. Ze všeho nejvíc by vás teď mělo trápit právě tohle a první byste měli aktualizovat své systémy. Také byste měli seřvat ty lidi, kteří vás přinutili používat zastaralou a nebezpečnou verzi jádra, ti si musí uvědomit, že takové chování je naprosto bezohledné.“
Monolitická jádra jsou daleko otevřenější k tomu, aby s nimi zacházeli lidé, kteří nejsou až tak dobří. Je to smutné, ale je to tak. Byl bych rád za svět, kde se používají mikrojádra, ale bojím se, že jsme příliš hloupí, než abychom toho dosáhli. Něco, něco, něco, proto nemůžeme mít hezké věci.
Stále musíme hodně myslet na výkon. Už je tu probíhající trend nasazování mechanismů obcházejících jádro kvůli výkonu a nové zvýšení ceny systémových volání nutně zesílí zájem vyhnout se jádru. Osobně nechci vidět, jak je jádro redukováno na zavádění systému a spouštění SSH pro správu počítačů.
Doufám, že tohle cvičení konečně zastaví probíhající jadernou nekrofilii v distribucích. Vím, že se tak nestane, ale naděje umírá poslední.
Zdá se, že řízeným odhalováním velmi důležitých chyb se daří dosahovat dvou věcí:
Nic z toho nemá nic společného s tím, kolik máme času na to přijít s co nejlepší možnou implementaci opravy. S tou technickou částí, víte?
Obvykle jsme vždy ladili s ohledem na latenci. Propustnost je „snadná“, ale téměř nikdy zajímavá.
—Linus Torvalds (díky Jimu Gettysovi)
A new kernel polling interface. Jonathan Corbet. 9. ledna 2018
Je užitečné dotazovat se (poll) skupiny deskriptorů souborů za účelem zjistit, který z nich zvládne provést I/O bez blokování. Je to dokonce tak užitečné, že jádro k tomu nabízí tři různá systémová volání (select(), poll() a epoll_wait() — plus nějaké další varianty). Jenže někdy ani tři možnosti nestačí. Aktuálně koluje návrh na čtvrté jaderné rozhraní pro dotazování. Jak je obvyklé, změna je motivována požadavky na výkon.
Christoph Hellwig 4. ledna zveřejnil nové dotazovací API založené na mechanismu asynchronního I/O (AIO). Někoho by to mohlo překvapit, jelikož AIO nepatří k nejoblíbenějším jaderným rozhraním a obvykle si nezíská mnoho pozornosti. AIO umožňuje zadávat I/O operace bez čekání na jejich dokončení. Čekání může být provedeno někdy jindy, je-li nutno. Jádro podporuje AIO již od doby vydání 2.5, ale vždy to bylo tak nějak neúplné. Přímé souborové I/O (původní způsob užití) funguje dobře, stejně jako síťové I/O. Mnoho dalších typů I/O ale není podporováno pro asynchronní použití – takové pokusy vedou na synchronní chování. V jistém smyslu je dotazování se přirozeným rozšířením AIO. Smyslem dotazování se je vyhnout se čekání na ukončení operací.
Patche přidávají nový příkaz (IOCB_CMD_POLL), který může být předán io_submit() v kontrolním bloku I/O (IOCB) spolu s ostatními obvyklými příznaky POLL*, které popisují požadovaný typ I/O — např. POLLIN pro data dostupná ke čtení. Tento příkaz, jako ostatní příkazy AIO, nebude (nezbytně) dokončen před návratem z io_submit(). Místo toho, když je určený deskriptor souboru připraven k požadovanému typu I/O, bude do fronty zařazena událost dokončení. Následné volání io_getevents() (nebo varianty io_pgetevents() přidané sadou patchů, ta během operace blokuje signály) vrátí tuto událost a volající aplikace bude vědět, že na uvedeném deskriptoru souboru může provést I/O. Dotazovací operace AIO vždy pracují v jednorázovém (one-shot) režimu. Takže jakmile se vygeneruje upozornění na dotaz a jsou zapotřebí další upozornění, je nutné pro daný deskriptor souboru poslat nový IOCB IOCB_CMD_POLL IOCB.
Zatím se toto rozhraní jeví složitější než stávající dotazovací systémová volání. Je tu ale výhoda, která spočívá v cyklické frontě (ring buffer) AIO. Tento bídně zdokumentovaný aspekt subsystému AIO mapuje cyklickou frontu do adresního prostoru volajícího procesu. Tento proces pak může konzumovat události oznámení přímo odtud, místo aby volal io_getevents(). Vícero oznámení lze přijmout zcela bez nutnosti vstupu do jádra a volání pro více deskriptorů souborů lze obnovit jediným voláním io_submit(). Hellwig uvedl ve zprávě doprovázející patche, že výsledkem je až 10% nárůst výkonu I/O frameworku Seastar. Hellwig nedávno poznamenal, že zlepšení výkonu roste až na 16 % u jader se zapnutou izolací tabulek stránek.
Uvnitř jádra může nové dotazovací rozhraní podporovat libovolný ovladač zařízení (nebo jiný subsystém, který exportuje strukturu file_operations), ale bude to vyžadovat nějaké drobné změny. Není však nutné podporovat (nebo dokonce ani vědět o) AIO obecně. V současných jádrech jsou všechna dotazovací systémová volání podporována metodou poll() ve struct file_operations:
int (*poll) (struct file *file, struct poll_table_struct *table);
Tato funkce musí provést dvě akce: nastavit upozornění na dobu, kdy bude příslušný soubor file připraven k I/O, a vrátit typy I/O, které lze provést bez okamžitého blokování. První se provede přidáním jedné nebo více čekacích front do poskytnuté tabulky table, ovladač na jedné z těchto front vykoná volání probuzení ve chvíli, kdy se stav zařízení změní. Aktuální stav připravenosti (readiness) vrací samotná metoda poll().
Podpora dotazování založeného na AIO vyžaduje rozdělit tyto dvě funkce do samostatných metod file_operations. Čili tato struktura obsahuje dva nové záznamy:
struct wait_queue_head *(*get_poll_head)(struct file *file, int mask); int (*poll_mask) (struct file *file, int mask);
(Patche samotné používají novou definici typu __poll_t pro mask, ale ta zatím není v hlavním repozitáři jádra.) Dotazovací subsystém zavolá get_poll_head(), aby získal ukazatel na čekací frontu, která dostane oznámení, když se změní stav připravenosti I/O zařízení. Aktuální stav připravenosti se získá voláním poll_mask(). Ovladač, který implementuje tyto dvě operace si nemusí (a pravděpodobně by ani neměl) zachovat implementaci staršího rozhraní poll().
Jedno možné omezení vlastní tomuto API spočívá v tom, že čekací fronta, která přijímá oznámení pro daný soubor file, může být pouze jedna. Stávající rozhraní naopak umožňuje více front a mnoho ovladačů tuto skutečnost využívá, například má různé fronty pro připravenost čtení a zápisu. Současné čekací fronty nabízejí tolik flexibility, že používání více front by již nemělo být nutné. Jestliže ovladač nemůže být změněn, „tak prostě nebude podporovat aio dotazování,“ řekl Hellwig.
Ke zveřejnění tohoto patche se zatím neobjevilo mnoho komentářů. Řada potenciálně zainteresovaných vývojářů byla v posledním týdnu zaneprázdněna jinými záležitostmi. S 10% nárůstem výkonu je ale těžké polemizovat, takže nějaká forma tohoto patche se pravděpodobně do hlavního jádra dříve nebo později dostane – koho to zajímá, může dále sledovat hlavní repozitář, jestli už to tam je. Zda se někdy dočkáme pátého dotazovacího rozhraní, je zatím otázkou.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.