Jaderné noviny – 9. 8. 2012: Výkonnostní regrese černé na bílém

28. 8. 2012 | Luboš Doležel

Články - Jaderné noviny – 9. 8. 2012: Výkonnostní regrese černé na bílém  

Aktuální verze jádra: 3.6-rc1. Citáty týdne: Linus Torvalds, Alan Cox. Závěr začleňovacího okna verze 3.6. Hlídání výkonnostních regresí v jádře.

Obsah

• Aktuální verze jádra: 3.6-rc1
• Citáty týdne: Linus Torvalds, Alan Cox
• Závěr začleňovacího okna verze 3.6
• Hlídání výkonnostních regresí v jádře

Aktuální verze jádra: 3.6-rc1

Aktuální vývojová verze jádra je 3.6-rc1 oznámená 2. srpna. Jako obvykle, dokonce i krátký přehled změn je příliš dlouhý na to, abych ho zasílal a mělo to smysl, ale mám tu svůj obvyklý souhrn: asi tak dvě třetiny změn jsou v ovladačích (vekou část tvoří ovladač CSR ze staging – bože, ta věc je velká a ukecaná i po té troše karpektomie). [...] Mimo ovladače patří něco přes třetina změn do arch (arm, x86, tile, mips, powerpc, m68k) a zbytek je docela rovnoměrně rozdělen mezi fs, šum v include souborech, síťování a jednoduše 'to všechno ostatní'. Pro zbylé změny od posledního týdne čtěte níže.

Stabilní aktualizace: verze 3.2.25 a 3.2.26 vyšly 3. a 5. srpna. Aktuálně probíhají revize jader 3.2.27, 3.4.8, 3.0.40 a 3.5.1.

Citáty týdne: Linus Torvalds, Alan Cox

Věřte mi: každý problém v informatice lze řešit nepřímým odkazem, ale tyto odkazy vyjdou *draho*. Běhání mezi ukazateli je na moderních CPU snad ta nejnákladnější věc, co můžete dělat.

-- Linus Torvalds

Když se vynořila myšlenka GNU OS, tak bylo obtížné si představit, že by každý měl na stole počítač, na kterém může běžet Unix. Při výběru mikrokernelu na bázi Machu šlo o to, aby se udržoval krok s tehdejším výzkumem, ale mělo to i společenský element. Vize byla taková, že bychom měli stroj, kde by například jakýkoliv uživatel mohl implementovat vlastní souborový systém, aniž by ovlivňoval ostatní. Z pohledu moderního PC to možná zní ujetě, ale na počítači sdíleném mezi více lidmi šlo o důležitý aspekt softwarové svobody.

Držet se u Machu a mít nepřátelský postoj k Linuxu nebylo moc chytré a mnoho vývojářů to FSF ještě neodpustilo, což je i jedním z důvodů, proč je označení „GNU/Linux“ tolik uráží.

Další věcí, co zvorali, bylo odmítnutí použití UZI, což by jim bývalo dalo základní, ale funkční OS ekvivalentní v7 Unixu roky před vydáním Linuxu. Kdyby to tak tehdy neudělali, Linux by tu nikdy nebyl a velká bitva o Windows by byla mnohem velkolepější.

-- lekce historie od Alana Coxe

Závěr začleňovacího okna verze 3.6

Linus uzavřel začleňovací okno verze 3.6 2. srpna, což je o několik dnů dříve, než se čekalo. Pro toto zjevně byly dva důvody: touha cosi vzkázat těm, kteří posílají požadavky na přetažení v poslední den, kdy je okno otevřené, a nadcházející dovolená. Nakonec přetáhl od předchozího souhrnu jen něco málo přes 300 změn, celkem tedy jde o 8587 změn v začleňovacím okně 3.6.

Těchto cca. 300 změn obsahovalo následující:

• Řadič šířky pásma blokového I/O byl přepracován tak, aby každá řídící skupina měla vlastní seznam požadavků namísto jednoho globálního. Toto sice zvětšuje paměťovou náročnost, ale jeho funkčnost se pak více blíží původnímu záměru, když je v systému mnoho požadavků.
• Na vytváření pevných a symbolických odkazů byla uvalena další sada omezení ve snaze zvýšit bezpečnost; měla by omezit spoustu zranitelností kolem dočasných souborů.
• Modul mapovače zařízení dm-raid nyní podporuje RAID10.
• Mezi nově podporovaný hardware patří DMA enginy OMAP.
• Funkčnost zmrazení souborového systému byla přepsána, aby byla robustnější; souborové systémy ve stromě byly upraveny, aby používaly tento nový mechanismus.

Nyní započala stabilizace. Pokud to půjde jako obvykle, tak můžeme verzi 3.6 očekávat v druhé polovině září.

Hlídání výkonnostních regresí v jádře

U softwarových projektů – otevřených, či nikoliv – není neobvyklé, aby měly sadu testů pro odhalení regresí dříve, než jejich dopad pocítí uživatelé. Jádru taková sada testů schází. Jsou pro to dobré důvody; většina jaderných problémů souvisí s určitým zařízením nebo řadičem a nikdo se kompletní výbavě s relevantním hardwarem ani zdaleka nepřibližuje. Proto jádro závisí zejména na testerech. Vývojový proces s tímto počítá v podobě stabilních stromů, kam se opravy dostanou brzo po jejich odhalení.

Přesto se najdou místa, kde by formálnější testování regresí pomohlo. Autor JN už za uplynulé roky viděl spoustu prezentací velkých firem. Mnoho z nich popisovalo stejný problém: zaktualizují jádro (často přitom přeskočí několik verzí) a zjistí, že pro jejich využití značně klesl výkon. Někdy za uplynulý rok práce se někde snížil výkon a nikdo to nepostřehl. Hledání výkonnostních regresí může být obtížné; často se vynoří jen v zátěžích, které se skrývají jen za několika vrstvami posedlých korporátních firewallů. Ale skutečnost, že se tyto regrese pomocí testů prakticky nehledají, to nijak nezlepšuje.

Mel Gorman nedávno spustil rozsáhlou sadu benchmarků na řadě strojů a zaslal výsledky. Narazil na zajímavé věci, které napovídají, na jaké výkonnostní problémy mohou uživatelé jádra v budoucnu narazit.

Jeho výsledky zahrnují sadu testů plánovače včetně benchmarků „starve“, „hackbench“, „pipetest“ a „lmbench“. Na systému s Intel Core i7 byly výsledky obecně dobré; narazil na regresi ve verzi 3.0, která byla následně opravena a na regresi v 3.4, která stále existuje, ale jádro se jinak povětšinou drželo dobře nebo se dokonce zlepšilo. Ale jen do doby, než se člověk podívá na jiné procesory. Na systémech s Pentiem 4 se různé regrese objevily v dobách 2.6.x a opět se to zhoršilo v 3.3. Na systému s AMD Phenom II se různé regrese objevily napříč řadou 3.x s tím, že výkon je celkově horší než s 2.6.32.

Mel má teorii, proč se to tak děje: hlavní jaderní vývojáři mají přístup k nejnovějším, nejvymakanějším procesorům a právě ty používají pro testování. Takže kód je pak pochopitelně optimalizován právě pro ně a starší procesory to odnesou. Svým způsobem by se to mělo dít právě tak; jaderní vývojáři pracují na kódu, který pak má běžet na budoucích systémech, takže na to by se měli soustřeďovat. Jenže k uživatelům se toto výdobytky nedostávají tak rychle; bezpochyby by ocenili, kdyby se jejich stávající systémy s novými jádry nezpomalovaly.

Nástroj sysbench spustil na třech různých souborových systémech: ext3, ext4 a xfs. U všech z nich se časem objevily regrese, u jader 3.1 a 3.2 šlo o obzvlášť špatný výkon ve swapování. Pak se to začalo zlepšovat; jistě za to může to, že se vývojáři soustředili na problémy se zpětným zápisem. Ale u ext3 je regresí stále dost, ačkoliv ext4 a xfs jsou na tom lépe. Souborový systém ext3 je nyní ve stavu údržby, proto nepřekvapí, že se věci nikam moc neposouvají. Problém je, že na světě je mnoho systémů, kde se ext3 používá; bylo by dobré, aby se výkon nezhoršoval, než se jejich majitelé odváží přejít na ext4.

Další test je navržen tak, aby zjistil, jak dobře se jádru daří obsluhovat požadavky na velkou alokaci paměti (požadavky na sérii fyzicky souvislých stránek). Zde je výsledek ten, že to jádru šlo dobře a zlepšuje se – až do verze 3.4. Mel k tomu říká:

Toto souvisí s odstraněním lumpy reclaim, na kterém kompakce nepřímo závisela. Toto naznačuje, že není zpětně získáváno dost paměti, aby se kompakce mohla posunout dále, nebo je kompakce vypínána kvůli neúspěšným pokusům.

Na druhou stranu funguje test dobře na nezatížených systémech, takže logika zabraňující fragmentaci zdá se pracuje tak, jak bylo zamýšleno.

Bylo zasláno velké množství dalších testů; řada z nich ukazuje nenápadné zanášení regresí v průběhu posledních dvou let. Svým způsobem to není potěšující; nikdo nechce, aby se výkon časem zhrošoval. Na druhou stranu je identifikace problému prvním krokem k jeho řešení; jakmile jsou k dispozici konkrétní ukazatele dokazující přítomnost regresí a kdy byly zaneseny, vývojáři mohou začít pracovat na jejich opravě. Až pak tito velcí uživatelé přejdou na nová jádra, tak už snad budou neduhy vyřešeny.

To je ale poněkud optimistický pohled na věc, tak by tedy člověk řekl podle minimální odezvy, jakou Melovy výsledky vyvolaly. Člověka to vede k myšlenkám, že většinu vývojářů tyto výsledky prostě nezajímají, ale to je možná mylné. Je také možné, že vývojáři jsou příliš zaneprázdnění hledáním původu regresí, než aby vykecávali na mailing listu. Zdali je tomu tak, se dozvíme v dalších jádrech.

Vývojáři si tyto testy mohou spouštět i na vlastní pěst; Mel celou sadu zveřejnil pod názvem MMTests. Pokud se testovací sada bude nadále rozvíjet a vývojáři ji budou používat, tak bychom s trochou štěstí mělí být v budoucnu svědky menšího počtu výkonnostních regresí. To by mělo uživatele systémů, ať už malých nebo velkých, potěšit.

Diskuse k tomuto článku

[avzgag]

o tom kernelu/systemu UZI slysim poprve.

http://www.cpmclub.de/zeitung/seite5.htm

[Radovan Garabík]

Otázka je, nakoľko by bol relevantný pre moderný (t.j. 16/32 bit) hardware...

Tiež som o UZI nepočul, ale o UZIX áno - ťažko povedať, aký je medzi nimi vzťah... UZIX vyzerá komplexnejší, prepracovanejší (má napr. podporu TCP/IP, ozajstný multitasking) ale zase potrebuje 2× toľko RAM. Ich popis je veľmi podobný - až natoľko, že je možné, že je to fork/clone.

[avzgag]

prvni linuxove jadro tez byl jenom pokusny kernel na hrani. to investovany cas a penize z linuxu udelaly to co je dnes.

[mimi.vx]

prvni varianta UZI byla pro Zilog Z80 co byl 8bit cpu vychazejici z inte 8086 ...

a druha verze byla na Zilogu Z280 co odpovidalo 286ce ..

[Michal Kubeček]

Zilog Z80 co byl 8bit cpu vychazejici z inte 8086

8080, ne 8086… :-)

[pc2005]

OMG já celou dobu myslel tohle UZI .

[Andrej]

UZI uses "total swapping" to achieve multiprocessing. ... UZI itself occupies the upper 32K of memory, and the currently running process occupies the lower 32K.

hmm, odswappovat cely 32kB blok s procesom na disk a priswappovat dalsi 32kB blok s pauznutym inym procesom - tomu hovorim poor man's multithreading.

[pc2005]

A jak by jsi to řešil ty?

[avzgag]

if (poor_mans_procesor ()) {

poor_mans_multithreading (); }

[Jiří Svoboda]

No ale to je přesně to, čemu se říkalo a co opravdu je swapovaní.

To, co se děje v kernelu dnes, ačkoliv se tomu swap říká, tak to žádné swapovaní není...

[deda.jabko]

Az na to, ze to neni poor man's multithreading, ale poor man's multiprocessing. Zajimalo by me, jak bys to na Z80 resils ty.

[Pev]

Autor JN už za uplynulé viděl

Autor JN už za uplynulé roky viděl.

[Luboš Doležel (Doli)]

Díky.

[little.owl]

Svým způsobem by se mělo dít právě tak; jaderní vývojáři pracují na kódu,

Svým způsobem by se to mělo dít právě tak; jaderní vývojáři pracují na kódu,

[MMMMMMMMM]

díky za pěkný článek (obvykle jaderné noviny nečtu, možná to byla chyba) :)

[pc2005]

Mezi nově podporovaný hardware patří DMA enginy OMAP.

To je divné, živě si vzpomínám, že jsem se před více než dvěma lety brodil ve vanilla kernelu při učení se jakej je rozdíl mezi DMA v OMAP2 a OMAP3.

[vandrovnik]

> aby se výkon časem zhrošoval.

No taky bych nechtěl na serveru žádné hrochy...

[Tommy_CZ]

:DDDD

[MMMMMMMMM]

+1