Jaderné noviny – 27. 6. 2013: Nižší latence blokového I/O

15. 7. 2013 | Luboš Doležel | Jaderné noviny | 3539×

Aktuální verze jádra: 3.10-rc7. Citáty týdne: Lennart Poettering, Greg Kroah-Hartman, Steven Rostedt. Van de Ven: Základní informace o P stavech na CPU Intel. Statistiky vývojového cyklu 3.10. Pollování blokových zařízení.

Obsah

• Aktuální verze jádra: 3.10-rc7
• Citáty týdne: Lennart Poettering, Greg Kroah-Hartman, Steven Rostedt
• Van de Ven: Základní informace o P stavech na CPU Intel
• Statistiky vývojového cyklu 3.10
• Pollování blokových zařízení

Aktuální verze jádra: 3.10-rc7

3.10-rc7 je poslední vývojovou verzí jádra. Bylo vydáno 22. června a bude pravděpodobně také poslední předverzí v řadě 3.10. rc7 obsahuje poměrně různorodou skupinu oprav napříč jádrem, (jako obvykle) jde hlavně o změny v ovladačích a architekturách. Tentokrát šlo hlavně o podporu multimédií. Ale jsou tam i věci ze srdce jádra jako důsledky změn v rutinách v cpu-idle a něco kolem časovačů pro nové režimy úplného NOHZ apod. Takže je to všude možně a naštěstí je to vcelku malé.

Stabilní aktualizace: verze 3.9.7, 3.4.50 a 3.0.83 byly vydány 20. června.

Stabilní jádra 3.9.8, 3.4.51 a 3.0.84 se aktuálně revidují a jejich vydání lze očekávat 27. června.

Citáty týdne: Lennart Poettering, Greg Kroah-Hartman, Steven Rostedt

Všechen váš řídící skupin je náš! [All your cgroups are belong to us!]

-- Lennart Poettering

Tak jsem se usadil a přečetl jsem si celou specifikaci. Počtení to bylo zábavné (mimochodem, zdá se, že vývojáři BIOSu si myslí, že vývojáři jádra Windows jsou na evolučním žebříčku níže, než jsou, a pokud vím, tak možná mají pravdu...) a celou supertajnou, pod NDA chráněnou specifikaci, co se obsluhy Thunderboltu v operačním systému týče, tu shrnu, pšššššt, nikomu neříkejte, že to dělám:

Thunderbolt je PCI Express s hotplugem, BIOS odvádí všechnu dřinu.

-- Greg Kroah-Hartman

Trasování je něco, s čím by se mělo zacházet jako s drogou. Stejně jako co se kouření na veřejných místech týče, trestejte pouze uživatele, nikoliv ty, co chtěji dýchat čerstvý vzduch.

-- Steven Rostedt

Van de Ven: Základní informace o P stavech na CPU Intel

Přečtěte si zajímavý zápisek od Arjana van de Vena pojednávající o fungování správy výkonu na současných procesorech Intel. Ve zkratce: je to složité. Klíčovou věcí je tu to, že jádro A se chová různorodě, nezávisle na tom, oč je žádáno, a to kvůli tomu, co dělá jádro B. Jinými slovy, dopředná prediktivní hodnota výběru stavu P na logickém CPU je poněkud omezená.

Statistiky vývojového cyklu 3.10

Vývojový cyklus 3.10 se blíží ke konci; v době psaní tohoto textu vyšla předverze 3.10-rc7 a jádro se dle očekávání stabilizuje. Jak se předpokládalo, verze 3.10 byla nejživějším vývojovým cyklem, co zatím kdy byl, s téměř 13 500 neslučovacími sadami změn přetaženými do hlavní řady (doposud). Dále najdete tradiční přehled původu techto změn.

Verze 3.9 měla svůj extra rekord v podobě 1388 vývojářů, kteří celkem změnami přispěli. Verze 3.10 se svými pouhými 1374 přispěvateli tento rekord nepřekonává, ale tato situace by se do vydání ještě mohla změnit. Vypadá to, že se komunita vývojářů nadále rozrůstá.

Nejaktivnějšími vývojáři ve verzi 3.10 byli:

Nejaktivnější vývojáři cyklu 3.10

Podle počtu sad změn H Hartley Sweeten 392 2,9 % Jingoo Han 299 2,2 % Hans Verkuil 293 2,2 % Alex Elder 268 2,0 % Al Viro 205 1,5 % Felipe Balbi 202 1,5 % Sachin Kamat 192 1,4 % Laurent Pinchart 174 1,3 % Johan Hovold 159 1,2 % Mauro Carvalho Chehab 158 1,2 % Wei Yongjun 139 1,0 % Arnd Bergmann 138 1,0 % Eduardo Valentin 138 1,0 % Axel Lin 112 0,8 % Lee Jones 111 0,8 % Lars-Peter Clausen 99 0,7 % Kuninori Morimoto 98 0,7 % Tejun Heo 97 0,7 % Mark Brown 97 0,7 % Johannes Berg 96 0,7 %

Podle počtu změněných řádek Joe Perches 34561 4,5 % Hans Verkuil 18739 2,4 % Kent Overstreet 18690 2,4 % Larry Finger 17222 2,2 % Greg Kroah-Hartman 16610 2,2 % Shawn Guo 12879 1,7 % Dave Chinner 12838 1,7 % Paul Zimmerman 12637 1,6 % H Hartley Sweeten 12518 1,6 % Al Viro 11116 1,4 % Andrey Smirnov 11107 1,4 % Mauro Carvalho Chehab 9726 1,3 % Laurent Pinchart 9258 1,2 % Jussi Kivilinna 8960 1,2 % Lee Jones 8598 1,1 % Sylwester Nawrocki 8305 1,1 % Artem Bityutskiy 8094 1,0 % Dave Airlie 7546 1,0 % Guenter Roeck 7510 1,0 % Sanjay Lal 7428 1,0 %

Umístění H. Hartleyho Sweetena na vrcholu je trvalý důsledek jeho neutuchající práce na pročišťování ovladačů Comedi ve stromu staging. Jingoo Han přispěl spoustou patchů pročišťujících ovladače, měnil kód tak, aby používal standardní pomocné funkce a „řízené“ API pro alokaci prostředků. Hans Verkuil zlepšil spoustu ovladačů pro příjem [acquisition] videa díky své nové pozici správce subsystému Video4Linux. Práce Alexe Edlera se zaměřuje na systém souborů Ceph a související blokové zařízení „RADOS“ a Al Viro implementoval velké množství změn v srdci jádra a v API. Tato pětice vývojářů se celkem postarala o téměř 11 % změn v jádře.

V kategorii počtu změněných řádků vítězí Joe Perches díky sadě patchů pročišťující bílé znaky, měnící formát ve printk(), vylepšující checkpatch.pl a ještě více. Kent Overstreet přidal subsystém cachování blokových zařízení bcache a řadu vylepšení v asynchronním I/O. 17 patchů od Larryho Fingera přidává nové funkce a podporu zařízení v ovladači rtlwifi a Greg Kroah-Hartman odstranil androidí ovladač „CCG“ USB gadget ze stromu staging.

Eviduje se více než 200 zaměstnavatelů, kteří práci na jádře 3.10 podpořili. Těmi nejaktivnějšími jsou:

Nejaktivnější zaměstnavatelé ve 3.10

Podle počtu sad změn (None) 1495 11,1 % Red Hat 1269 9,4 % Intel 912 6,8 % Linaro 877 6,5 % Texas Instruments 765 5,7 % (Unknown) 746 5,5 % Samsung 615 4,6 % IBM 402 3,0 % Vision Engraving Systems 392 2,9 % Google 350 2,6 % SUSE 332 2,5 % Renesas Electronics 331 2,5 % Cisco 300 2,2 % Inktank Storage 277 2,1 % Broadcom 182 1,3 % NVidia 180 1,3 % Freescale 175 1,3 % Oracle 175 1,3 % Trend Micro 139 1,0 % Fujitsu 138 1,0 %

Podle počtu změměných řádků (None) 118326 15,3 % Red Hat 88080 11,4 % Linaro 64697 8,4 % Intel 50641 6,6 % Google 33342 4,3 % Cisco 24109 3,1 % (Unknown) 24033 3,1 % Samsung 20893 2,7 % Texas Instruments 20289 2,6 % NVidia 18470 2,4 % Linux Foundation 16759 2,2 % Renesas Electronics 15777 2,0 % IBM 14385 1,9 % QLogic 14165 1,8 % Synopsys 13698 1,8 % Vision Engraving Systems 13111 1,7 % Broadcom 12770 1,7 % Synapse Product Development 11107 1,4 % OpenSource AB 9584 1,2 % SUSE 9479 1,2 %

Red Hat se vrátil zpět na první místo mezi firmami, i tak ale nepřekonal příspěvky od dobrovolníků.

Vidíme zde pokračování dosavadních trendů: čím dál větší aktivitu ze strany subjektů od mobilních a embedded zařízení. Celkově se mašinérie vývoje jádra chová stále stejným, předvidatelným a produktivním způsobem.

Pollování blokových zařízení

Počet aplikací citlivých na latenci se na Linuxu zvyšuje, výsledkem je to, že se více změn týkajících se latence dostává i do jádra. Nedávno jsme se dívali na patch přidávající pollování do ethernetových ovladačů, aby kritické úlohy díky možnosti pollování měly co nejnižší latenci. Ale co kdybyste chtěli co nejnižsí možnou latenci u požadavků blokového I/O? Patch pro pollování blokového ovladače od Matthewa Wilcoxe se snaží řešit právě toto.

Podle Matthewových slov je tu skupina uživatelů, kteří jsou pro co nejnižsí latence při obsluze blokových I/O požadavků ochotni udělat mnoho:

Problémem je, že někteří lidé, co se na tyto technologie dívají, jsou šílení. Chtějí „obejít jádro“ a „dělat I/O v uživatelském prostoru“, protože „jádro je příliš pomalé“. Tento patch je součástí snahy, jak jim ukázat, jak moc šílení jsou.

Patch přidává nové zpětné volání ovladače do struct backing_dev_info::

int (*io_poll)(struct backing_dev_info *bdi);

Tato funkce, pokud je přítomna, by měla provádět pollování na daném zařízení dotazující se na dokončené I/O operace. Pokud jsou nějaké nalezeny, pak by toto mělo být signalizováno zpět do blokové vrstvy; návratovou hodnotou je počet nalezených operací (nebo záporné číslo při chybě).

V rámci blokové vrstvy je funkce io_poll() volána, kdykoliv má proces spát kvůli čekání na probíhající operaci. Tím, že tam přidáme volání poll, Matthew doufá, že se pollování nespustí, pokud jsou na práci další věci; například to umožní zadání vícero operací, aniž by byla spuštěna smyčka pro poll. Jakmile ale proces opravdu potřebuje výsledek zadané operace, pak je místo uspání použito pollování.

Pollování pokračuje do té doby, než je splněna jedna z několika podmínek. Jednou z nich je pochopitelně dokončení operace, na kterou proces čeká. Pokud k němu nedošlo, pak bude pollování pokračovat, dokud nepřijde signál nebo dokud plánovač neřekne, že by rád přepnul na jiný proces. Jinými slovy se pollování zastaví, pokud se spustitelným stane proces s vyšší prioritou nebo pokud vyprší čas přidělený aktuálnímu procesu. Proto ačkoliv pollování probíhá v jádře, je omezeno procesorovým časem dostupným danému procesu.

Linusovi se tento přístup nelíbil, podle něj pollování stále mrhá časem CPU, i když se o CPU aktuálně nesoupeří s žádným jiným procesem. Přesto ale není proti pollování jako takovému; jen nechce, aby k němu docházelo, pokud by se mohly objevit nějaké jiné spustitelné procesy. Proto navrhl, že by pollování mohlo být přesunuto do vlákna idle. Pak by k pollování docházelo jen tehdy, pokud by CPU mělo být opravdu naprosto nečinné, což by bylo zárukou, že pollování nebude stát v cestě jiným procesům, co chtějí odvádět nějakou práci.

Linus se tentokrát ale možná netrefil. Správce blokové vrstvy Jens Axboe odpověděl, že řešení s používáním idle vlákna nebude fungovat. Pokud musíte uskutečnit přepnutí kontextu, tak jste právě odstranili všechny přednosti pollování. Také řekl, že patch aktuálně dělá pollování na (téměř) správném místě, právě tam, kde jsou potřebné informace dostupné. Proto je Jens nakloněn začlěnění něčeho, co vypadá jako tento patch; pak to pravděpodobně přijme i Linus.

Jens ale požádal o něco chytřejšího při rozhodování, kdy se má pollování použít; v patchi se tak děje vždy u každého zařízení, které poskytuje funkci io_poll(). Lepší by podle něj bylo, aby si procesy mohly o pollování zažádat, protože i na systémech citlivých na latenci nebude pollování nutné u všech procesů. Procesy, které nepotřebují extrémně nízkou latenci, by nemusely mrhat svůj čas CPU pollováním I/O.

Před začleněním se proto patchi ještě určitě dostane nějakých úprav. Ale přínos je opravdový: při Matthewových pokusech na zařízení NVMe poklesla latence z přibližně 8 µs na 5,5 µs – znatelné zlepšení. Přínos se více ukáže s rostoucí rychlostí SSD; jak se čas potřebný pro provedení I/O operace bude blížit 1 µs, tak se dodatečných 2,5 µs režie bude více projevovat. Uživatelé, kterým latence vadí, budou chtít tuto latenci nějak odstranit; vyřešení problému v jádře je ideální pro to, aby z této práce měli užitek všichni.

       

Komentáře