Jaderné noviny – 23. 8. 2012: Optimalizace jádra pomocí LTO

10. 9. 2012 | Luboš Doležel | Jaderné noviny | 3064×

Aktuální verze jádra: 3.6-rc3. Citáty týdne: Matthew Garrett, Ingo Molnar, Andrew Morton, Thomas Gleixner. Dlouhodobá údržba jádra 3.4. Optimalizace typu LTO v jádře.

Obsah

• Aktuální verze jádra: 3.6-rc3
• Citáty týdne: Matthew Garrett, Ingo Molnar, Andrew Morton, Thomas Gleixner
• Dlouhodobá údržba jádra 3.4
• Optimalizace typu LTO v jádře

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

Aktuální vývojová verze jádra je 3.6-rc3 vydaná 22. srpna. Krátký seznam změn najdete níže, ale není tam nic, kvůli čemu bych vykřikoval 'OMG! Děs běs!' nebo bych cítil potřebu to vyzdvihovat. Jsou tam jen běžné aktualizace a opravy.

Ještě předtím vyšlo 3.6-rc2, a to 16. srpna. Tak či tak to ale nebylo tak zlé. Ano, ignoroval jsem několik žádostí o přetažení, ale musím říct, že jich nebylo tolik a jinak to byla docela pohoda. Jasně, je tam přes 330 commitů, ale vzhledem k tomu, že to bylo za dva týdny, nejde u raných -rc o žádné překvapení (a spíš je to málo). Ano, u 3.5 toho bylo v -rc2 méně, ale to byla výjimka.

Stabilní aktualizace: verze 2.6.34.13 a 3.2.28 vyšly 20. srpna.

Citáty týdne: Matthew Garrett, Ingo Molnar, Andrew Morton, Thomas Gleixner

To, že je naše spotřeba energie horší než na jiných operačních systémech, je téměř výhradně jen kvůli tomu, že pouze jeden z našich tří ovladačů GPU implementuje použitelnou správu výkonu.

-- Matthew Garrett

Přesun 'pravidel' do uživatelského prostoru bylo naprosté selhání, hlavně kvůli tomu, že za získání dobrých výsledků není zodpovědný žádný projekt/subsystém. To je důvod, proč názoru „pravidla by neměla být v jádře“ tak vzdoruji.

Ingo Molnar

Z „inline“ je teď vágní, ubohá a nepoužitelná věc. Problém je v tom, že čtenář netuší, zda autor opravdu vyžadoval inline.

Pokud jsme dobře zvážili rozhodnutí mít funkci inline, měli bychom nyní vždy používat __always_inline. Pokud jsme dobře zvážili to, že funkce nemá být inline, měli bychom použít noinline. Pokud je nám to jedno, neměli bychom to označovat nijak.

Pro „inline“ tu tedy už není místo?

-- Andrew Morton

Copy & paste je hlavní přičinou nenápadných chyb.

-- Thomas Gleixner

Dlouhodobá údržba jádra 3.4

Greg Kroah-Hartman oznámil, že jádro řady 3.4 bude dostávat stabilní aktualizace po dobu alespoň dvou let. Přidává se tak k řadě 3.0 (které zbývá ještě rok podpory).

Optimalizace typu LTO v jádře

Jádro je zpravidla tím, co určuje maximální rychlost, jakou může zátěž běžet, proto není divu, že jsou vývojáři vždy na pozoru, jak by se dalo systém zrychlit. Spoustu práce se dá vynaložit na optimalizacích, které se na pohled mohou zdát malé. Takže jakmile se vyskytne příležitost jádro zrychlit, aniž by se musely přepisovat výkonnostně kritické části, je o to pochopitelně solidní zájem. Zda „optimalizace za doby linkování“ (LTO; Link-Time Optimization) podporovaná v posledních GCC představuje takovou příležitost, to ještě nikdo nedokázal, ale Andi Kleen je odhodlán na to přijít.

Myšlenkou LTO je prozkoumat celý program po kompilaci všech souborů a využít všech dodatečných příležitostí k optimalizacím. Nejvýznamnější příležitostí je asi změna malých funkcí na inline. Kompilátor se také může chovat agresivněji, co se detekce a odstranění nepoužitého kódu a dat týče. Pod kapotou funguje LTO tak, že do výsledného objektového souboru ukládá interní mezikód kompilátoru (GIMPLE), kdykoliv je kompilován zdrojový kód. Samotný krok LTO se pak provádí tak, že se načte všechen GIMPLE kód do jediného obrazu a znovu se zapíše (pravděpodobně) více optimalizovaný objektový kód.

Funkce LTO se objevila poprvé v GCC 4.5, ale skutečně užitečná je až od verze 4.7. Stále má řadu omezení; jedním z nich je to, že všechny objektové soubory musejí být zkompilovány pomocí stejných voleb na příkazové řádce. Jak se ukázalo, toto omezení představuje problém pro jádro.

Andiho LTO patch se skládá ze 74 sad změn – to není zrovna málo. Ale ukazuje se, že většina těchto změn dělá tu samou základní věc: zajišťuje, že kompilátor ví, že některé symboly jsou potřeba, i když vypadají jako nepoužité; to zabraňuje LTO, aby je odstranilo. Například jde o symboly exportované modulům, které nemusejí mít v jádře samotném žádné použití, ale je nezbytné je zachovat právě pro později načtené moduly. Andiho první patch proto definuje nový atribut (__visible), kterým jsou takové symboly označovány; většina ostatních patchů slouží k doplnění atributů __visible všude tam, kde je to nutné.

Mimo to se tam najdou nějaké ty opravy konkrétních problémů, na které se přišlo při sestavování s LTO. Vypadá to, že funkce s dlouhým výčtem argumentů mohou dostat poškozené argumenty, pokud jsou tyto funkce převedeny ve fázi LTO na inline; tomu je třeba se vyhnout pomocí noinline. Andi si postěžoval: Kéž by byl obecný způsob, jak toto ošetřit. Vypadá to jako tikající bomba.. Obecně uznává, že LTO může do jádra zanést nové chyby související s optimalizacemi; jejich nalezení bude asi docela výzva.

Pak přicházíme k požadavku, že všechny soubory musejí být sestaveny se stejnými volbami. Současná jádra takto sestavována nejsou; v odlišných částech stromu se používají jiné volby. Někde se tento problém dá obejít zákazem určitých optimalizací, které závisí na použití jiných voleb než ve zbytku stromu. Jinde se zase musejí zakázat určité funkce, aby se LTO mohlo použít. Mezi ně patří funkce „modversions“ (umožňující používání jaderných modulů s více než jednou verzí jádra) a trasovač funkcí. Problém s modversions asi má řešení; rozchození ftrace si ale může vyžádat změny v GCC.

Pro využití GCC LTO je ale pochopitelně potřeba udělat změny v sestavovacím systému. V době psaní tohoto textu je nutné použít poslední verzi GCC; pro funkčnost LTO je taktéž nutné nainstalovat vývojovou verzi balíčku binutils. Dokonce i minimalistická podoba jádra vyžaduje cca. 4 GB paměti pro průchod LTO; sestavení „allyesconfig“ si může vyžádat až 9 GB. Vzhledem k tomu je používání 32bitových systémů pro sestavování s LTO vyloučené; je ale samozřejmě možné sestavit 32bitové jádro na 64bitovém systému. Sestavení také potrvá až čtyřikrát déle než bez LTO. Proto je nepravděpodobné, že by sami vývojáři LTO používali pro svou práci, ale zájem o to mít mohou distributoři a další, kdo sestavují produkční jádra.

Skutečnost, že většina lidí nebude chtít LTO použít, představuje problém. Vzhledem k potenciálu LTO zanášet drobné chyby, ať už vinou nedorozumění v optimalizacích nebo chyb v LTO jako takovém, je před použitím LTO v produkčních jádrech rozhodně nutné rozsáhlé testování. Jenže když nebudou vývojáři a testeři ochotni dělat taková těžkotonážní sestavení, tak se jádru testování nemusí dostávat. Proto bude těžké dosáhnout takové úrovně důvěryhodnosti, aby se LTO běžně dostávalo do jader v produkčním nasazení.

Vzhledem k výše uvedeným skutečnostem, velikosti patche a trvalému břemenu v podobě údržby funkčnosti LTO to může vyvolávat otázku, zda to za tu práci vůbec stojí. A v tento moment se tedy dostáváme k číslům: o kolik je jádro s LTO rychlejší? Ostrá čísla teď nejsou zrovna k dispozici; patch pro LTO je stále nový a musí se toho ještě hodně opravit. Andi hlásí, že při běhu hrubého testu dělalo zrychlení nějakých 5 %, ale na sestavování jádra byl dopad skoro nulový. V některých síťových testech dělalo zrychlení až 18 %. Našly se i určité „drobné regrese“. Čísla jsou jen orientační, ale Andi věří, že jsou dostatečně povzbuzující na to, aby to stálo za to v práci pokračovat dál; také očekává, že se implementace LTO v GCC časem zlepší.

Andi dále poznamenal, že LTO by v dlouhodobém horizontu mohlo zvýšit kvalitu kódu jádra tím, že by už nebylo nutné dávat inline funkce do include souborů.

Tak jako tak je patch v dosti rané fázi vývoje; je nepravděpodobné, že by došlo v dohledné době k začlenění, třeba i v podobě experimentální funkce. V delším horizontu by to ale mohlo přinést rychlejší jádra; užívání LTO v jádře by také mohlo pomoci hnát vpřed vývoj implementace v GCC, což by ve výsledku prospělo všem projektům. Z těchto důvodů jde bez pochyby o úsilí, jež stojí za pozornost.

       

Komentáře

[jaime]

pouze jeden z našich tří ovladačů GPU implementuje použitelnou správu výkonu, ke kterymu ovladaci Garrett referuje?

[Kamil Páral]

Pravděpodobně Intel.

[Luboš Doležel (Doli)]

Mně překvapuje, že se někdo intenzivně zabývá funkcí, která evidentně není ani zdaleka doladěná...

[Marv-CZ]

Štěstí přeje připraveným. Až bude doladěná, bude (možná) jádro připravené ji využít.

[Jindřich Makovička]

Mně to přijde jako rozumná investice. V kernelu pomůže LTO odhalit chyby, které tam jsou, ale neprojevují se navenek (zatím) díky tomu, že překladač neoptimalizuje tolik, jak by mohl. A vývojáři GCC zase budou mít na čem LTO testovat. Všichni získají a navíc se obejde problém slepice versus vejce.

[Sten]

Kdo tu funkci doladí, když se jí nebudete zabívat?

[Sten]

Samozřejmě zabývat, původně jsem tam měl zajímat a na to í jsem zapomněl

[Luboš Doležel (Doli)]

Hlavně mi jde o to, že je trochu divný vymýšlet workaroundy (jako ten noinline) a netlačit jen na opravu chyby. To by mi za to nestálo.

[Sten]

No tak on určitě na opravu chyby tlačí, otázka ale je, za jak dlouho to GCC opraví, a do té doby je potřeba workaround, aby to mohli testovat i na jiných místech