Jaderné noviny – 24. 10. 2013: Energeticky efektivnější plánovač

11. 11. 2013 | Luboš Doležel | Jaderné noviny | 4030×

Aktuální verze jádra: 3.12-rc6. Citáty týdne: Matt Porter, Thierry Reding, Linus Torvalds. Nftables přetaženo do verze 3.13. Mini-sumit o plánovači s ohledem na spotřebu energie: Potřeba metrik; Co dělat dál.

Obsah

• Aktuální verze jádra: 3.12-rc6
• Citáty týdne: Matt Porter, Thierry Reding, Linus Torvalds
• Nftables přetaženo do verze 3.13
• Mini-sumit o plánovači s ohledem na spotřebu energie
  • Potřeba metrik
  • Co dělat dál

Aktuální verze jádra: 3.12-rc6

Aktuální vývojová verze jádra je 3.12-rc6 vydaná 19. října. Linus k ní řekl: Během uplynulého týdne se nic velkého neudálo a příští týden bude asi také poklidný, jelikož hodně hlavních správců bude v Edinburghu na KS [Jaderný sumit].

Stabilní aktualizace: verze 3.11.6 a 3.10.17 vyšly 18. října a byly následovány verzemi 3.4.67 a 3.0.101 22. října. Toto je konec údržby řady 3.0: Další vydání 3.0.x už dělat NEbudu. Pokud stále závisíte na řadě 3.0.x, měli byste přejít na novou řadu 3.10.x nebo v horším případě na 3.4.x.

Citáty týdne: Matt Porter, Thierry Reding, Linus Torvalds

[Stromy zařízení mají] mnoho výhod. Bylo by skvělé jich využívat, dokud to nebude mít dopad na rychlost změn a ochotu rozvíjet kód, což vždy bylo silnou stránkou vývojových procesů v jádře. Tato přednost je až příliš cenná na to, abychom ji vyměnili za vizi „Strom zařízení jako ABI“.

-- Matt Porter

Jsi si jistě vedom toho, že dle obecné shody má zodpovědnost za vývoj generické implementace třetí člověk, co ji přepisuje, což pro změnu v tomto případě nejsem já...

-- Thiery Reding

Pokud jste firma, co si myslí, že vaše drobná změna v jádře vám dává náskok před konkurencí, pak asi budete čelit ekonomickým problémům. Měli byste se raději starat o to, abyste vyrobili ten nejlepší hardware za co nejnižší cenu.

-- Linus Torvalds

Nftables přetaženo do verze 3.13

Pro ty z vás, kteří se zajímají o nftables, náhradu subsystému pro firewall v jádře, je tu novinka: tento kód byl právě přetažen do stromu net-next. To znamená, že pokud se neobjeví nějaké problémy, tak dojde k začlenění během vývojového cyklu 3.13. Tento kód ještě není připraven na to, aby nahradil iptables, ale po zařazení do hlavní řady by se rychlost prací měla zvýšit. Kdokoliv, kdo by chtěl nftables vyzkoušet, si může přečíst rychlé howto.

Mini-sumit o plánovači s ohledem na spotřebu energie

První den na Jaderném sumitu 2013 byl vyhrazen pro různé drobné mini-sumity na všelijaká témata. Jedním z těchto témat byla kontroverzní oblast plánovače, který bere ohled na spotřebu energie [power-aware scheduling]. Byla zaslána spousta patchů, které se snaží vylepšit plánovač, ale žádný z nich se hlavní řadě jádra nepřiblížil. Na tomto setkání se sešli vývojáři ze světa embedded zařízení a hlavní vývojáři plánovače, aby se pokusili věci posunout kupředu; ještě se uvidí, jestli se jim to podařilo, ale jisté kroky se podařilo určit.

Jedním z organizátorů této debaty byl Morten Rasmussen, autor sady patchů big LITTLE MP. Začal programem tohoto setkání a podpůrnými slajdy; probírala se tato témata:

• Sjednocení pravidel správy výkonu, která jsou aktuálně rozdělena mezi vícero nekoordinovaných subsystémů.
• Slučování úloh [Task packing]. Byly zaslány různé patche, ale nikam jsme se nedostali.
• Ovladače výkonu a hlavně vytvoření řádné abstrakce pro správu výkonu na úrovni hardwaru.

Pokusil se diskuzi otevřít tématem subsystémů cpufreq a cpuidle, ale netrvalo dlouho, než se konverzace posunula jinam.

Potřeba metrik

Ingo Molnar přišel se stížností: žádná z prací na správě výkonu nezačíná měřeními chování výkonu systému. Bez sourodého přístupu k měření dopadů patche není žádný pořádný způsob, jak rozhodnout, které patche by měly být začleněny. Nemůžeme začlenit patche do plánovače jen na základě víry, že věci nějak zlepší.

Poté se rozběhla diskuze o tom, jak by taková metrika měla být vytvořena. Je jasné, co by vývojáři plánovače chtěli: jak dlouho trvalo spustit určený objem práce a kolik energie bylo spotřebováno? Někdo má zájem znát i nejhorší latenci, kterou zátěž zaznamenala během svého běhu. Jakmile budeme mít opětovně vytvořitelná čísla pro tyto kvantity, pak by mělo být možné zjistit, které patche pomáhají při jaké zátěži a posouvají věci kupředu.

V této oblasti se ale nepodařilo dosáhnout shody všech. Mark Gross z Intelu tvrdil, že tento typ metriky výkonu je „cestou do pekla“. Místo toho řekl, že benchmarky výkonu by se měly zaměřit na nízkoúrovňové chování jako stavy spánku procesoru ("C"). Pro jakýkoliv stav spánku musí procesor zůstat v tomto stavu po určitou dobu, než dojde ke skutečným úsporám. Proto musí subsystém cpuidle dělat odhady, jak dlouho musí být procesor nečinný, než vybere odpovídající stav spánku. Doba nečinnosti je něco, co se pak dá měřit; později pak člověk může získat přehled o tom, jak moc odpovídají odhady jádra skutečnosti. To je podle Marka benchmark, který by jaderní vývojáři měli používat.

Jiní argumentovali, že odhad času nečinnosti je nízkoúrovňové měření, které nemusí moc dobře odpovídat tomu, co uživatelé vlastně chětjí: mít práci hotovou rychle, bez nepřijatelných latencí a s minimální spotřebou energie. Ale získat skutečná měření spotřeby je těžké; výrobci procesorů nejsou ochotní tyto údaje jádru dávat. Žádnou dobrou sadu metrik pro zhodnocování patchů pro plánovač se tedy nepodařilo najít. Ingo nakonec řekl, že první patch, který do adresáře tools přidá rozumný benchmark zaměřený na spotřebu energie, může být zařazen; pak se může doladit.

Co dělat dál

Odtamtud se diskuze přesunula k tématu, jak zlepšit charakteristiku spotřeby v plánovači. Bylo odsouhlaseno, že je nutné mít lepší mechanismus, jak by aplikace mohla jádru sdělit své požadavky na latenci. S těmito požadavky na latenci je pak nutné opatrně zacházet: není možné držet všechna CPU v systému vzhůru jen proto, že aplikace na jednom z nich potřebuje latenci v určitých mezích.

Probíralo se přidání určitého modelu využívání energie do simulátoru – buď nástroje linsched, nebo perf sched – aby bylo možné dělat standardizované testování patchů s určitou zátěží. Linsched byl vyvíjen stážistou v Google, ale práce nebyla dokončena, proto ještě není připraven pro zařazení. Ingo poznamenal, že prostředky nutné pro odvedení této práce jsou k dispozici; konec konců tu máme vývojáře, jež mají zájem na začlenění kódu pro zohlednění spotřeby energie do plánovače.

Rafael Wysocki se zeptal vývojářů plánovače: jaké informace od hardwaru potřebujete na to, abyste dělali lepší rozhodnutí při plánování? Odpověděl Paul Turner: náklady na běh systému při daném nastavení; Peter Zijlstra dodal, že by rád znal náklady na spuštění dodatečného CPU. Markovou odpovědí bylo to, že toto vše závisí na tom, jaká generace hardwaru se používá. Intel obecně není moc ochoten tyto informace zpřístupnit, což je postoj, který moho vývojářů plánovače hněvá.

Jak čas běžel, tak se během diskuze podařilo víceméně ujasnit, co by komunita okolo plánovače chtěla. K infrastruktuře domén plánování by měla být připojena určitá metrika nákladů; měla by plánovači říkat, jaká je cena spuštění daného procesoru. Tato informace by se musela objevovat na více úrovních; spuštění prvního procesoru ve fyzickém jiném balení bude například jednoznačně stát víc než přidání procesoru v již aktivním balení.

S tímto souvisí koncept stavů výkonu („P"), který je obecně považován za “frekvenci CPU". Hovořit o frekvenci je poněkud zastaralé, ale přetrvává to tak v subsystému cpufreq, který by, jak skoro všichni souhlasili, měl být odstraněn. Plánovač musí rozumět nákladům (a změnám ve výkonu) spojeným se změnou P stavu; to by mu umožnilo rozhodovat se mezi navýšením P stavu a přesunem úlohy na nové CPU. Jak by procesor tyto údaje zveřejňoval, není jasné, ale pokud by byly dostupné, mohlo by se díky tomu dělat lepší rozhodnutí.

Jak by se tato rozhodnutí měla dělat, zůstává nejasné. Mluvilo se o přípravě sady standardizovaných zátěží, ale to je předčasné. Paul navrhoval, že by mohla vzniknout sada „příběhů“, které by v lidsky čitelné formě popisovaly určité zátěže. Jakmile by byla sestavena takováto sada příběhů, pak by vývojáři mohli začít hledat společné části, na základě nichž by pak mohli vymyslet algoritmy pro lepší a energeticky ohleduplnější plánování.

Krátce se mluvilo o Mortenových nedávných patchích pro plánovač. Dohodlo se, že představují rozumný začátek práce na přesunu povědomí o frekvenci CPU a nečinnosti do plánovače. Bylo navrženo, že by se nejprve do plánovače přesunulo cpuidle; většina vývojářů by aktuálně nejradši viděla odstranění cpufreq.

V tento moment bylo účastníkům připomenuto, že oběd začal už před necelou hodinou. Materiály, na základě kterých by vývojáři mohli pracovat, jsou přinejmenším stále vágní, ale přesto se podařilo dopracovat k některým hodnotným závěrům, kterým vévodí potřeba vytvořit sadu použitelných metrik. To by mělo stačit na to, aby se vývoj mohl drobnými krůčky posouvat vpřed.

       

Komentáře