Portál AbcLinuxu, 15. května 2024 17:05
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í 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.
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.
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.
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?
Copy & paste je hlavní přičinou nenápadných chyb.
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).
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.
pouze jeden z našich tří ovladačů GPU implementuje použitelnou správu výkonu, ke kterymu ovladaci Garrett referuje?
10.9.2012 08:52
Kamil Páral | skóre: 13
| blog: Kamil Páral
| Brno
Pravděpodobně Intel.
10.9.2012 09:46
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
10.9.2012 16:34
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.