Jaderné noviny – 20. 6. 2013: Energeticky efektivní plánovač

9. 7. 2013 | Luboš Doležel | Jaderné noviny | 3468×

Aktuální verze jádra: 3.10-rc6. Citáty týdne: Steven Rostedt, Al Viro, Linus Torvalds, Greg Kroah-Hartman. Plánovač ohleduplný ke spotřebě energie.

Obsah

• Aktuální verze jádra: 3.10-rc6
• Citáty týdne: Steven Rostedt, Al Viro, Linus Torvalds, Greg Kroah-Hartman
• Plánovač ohleduplný ke spotřebě energie

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

Aktuální vývojová verze jádra je 3.10-rc6 vydaná 15. června. V oznámení Linus Torvalds zmínil, že počty patchů (226 od -rc5) se lehce snižují. Ale i pokud jste luddita a ještě jste se neseznámili s rozkošemi práce s gitem, pak byste jistě měli mít zájem používat poslední jádro. Tak se na to vrhněte a odhalte případné regrese. Protože oprav tam máme všude hodně...

Stabilní aktualizace: Greg Kroah-Hartman dne 13. června vydal stabilní jádra 3.9.6, 3.4.49 a 3.0.82. Stabilní jádro 3.2.47 vydal Ben Hutchings dne 19. června.

Jádra 3.9.4, 3.4.50 a 3.0.83 se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté.

Citáty týdne: Steven Rostedt, Al Viro, Linus Torvalds, Greg Kroah-Hartman

OK, ještě jsem tu nenašel žádnou chybu, ale ty tvé bývají zákeřnouškééé. My neradi zákeřnoušké a musíme najít miláška!

Kvůli tomuhle kódu začínám vypadat jako Glum.

-- Steven Rostedt

Můj názor je ten, že se vším, co má co do činění s NetWarem, je nejlepší, když zacházejí fajn lidé z Miskatonické univerzity, a to se všemi náležitostmi, když se pracuje se zárodky po dávných bozích.

-- Al Viro

Když už jsme u toho, tak křečci jsou opravdu zlá stvoření.

Samozřejmě, že můžete svého malého chlupatého křečka Ferdíka mít rádi, ale pod roztomilým a skromným zevnějškem se skrývá vypočítavé a černé malé srdce.

Takže za zaklínání křečků není potřeba se omlouvat. Můžou si za to sami.

-- Linus Torvalds

No jasně, rád se spokojím s „Můžu to udělat později“, pokud dotyčnému nebude zase vadit mé „Začlením to později“ :)

-- Greg Kroah-Hartman

Plánovač ohleduplný ke spotřebě energie

Nedávno se na LWN psalo o prvotním návrhu od Inga Molnara týkajícího se plánovače ohleduplného ke spotřebě energie. Fragmentace zodpovědnosti za správu výkonu CPU mezi plánovačem, frequency governorem a subsystémem CPUidle musí podle něho být nahrazena jednotným řešením, které umístí rozhodování týkající se správy výkonu na místo, kde je vždy nejvíce informací: do plánovače. Po tomto prohlášení následovala velmi živá diskuze a postupně se začíná rýsovat možné řešení. I nadále jde ale o složitý problém.

Převelení zodpovědnosti za rozhodnutí týkající se správy výkonu CPU na plánovač CPU má určitý šmrnc, plánovač je snad v dobrém postavení na to, aby věděl, zda systém bude v nejbližší době potřebovat výpočetní výkon. Ale tato myšlenka hned naráží na probém kvůli jinému trendu v jádře: rozhodnutí týkající se správy výkonu se přesouvají z plánovače do nízkoúrovňového kódu ovladačů. Jak Arjan van de Ven poznamenal už v květnu v diskuzi na Google+, politika správy výkonu u procesorů značky Intel se v posledních jádrech řeší v kódu specifickém pro tato CPU:

Ačkoliv si uvědomuji, že toto může být kontroverzní, tak říkám, že kombinujeme řídící algoritmus s ovladačem CPU na jediném místě. Pravdou je, že takové řídící algoritmy jsou specifické pro konkrétní CPU, idea obecných governorů „pro všechna CPU“ je už od začátku mylná; chování hardwaru je pro algoritmy klíčové.

Arjan upozorňuje, že debaty kolem řízení frekvencí a napětí CPU se nedotýkají jedné důležité věci: současné procesory mají komplikovanější správu výkonu a mezi jednotlivými generacemi hardwaru se značně liší. Plánovač není správným místem pro veškeré nízkoúrovňové informace; místo toho patří do nízkoúrovňového kódu specifického pro daný hardware.

Obecně ale lidé souhlasí, že předávání více informací mezi plánovačem a nízkoúrovňovým kódem pro správu výkonu by bylo ku pomoci. Zejména je velký zájem o lepší integraci mezi vyvažováním zátěže v plánovači (který rozhoduje o tom, jak rozdělit procesy mezi dostupnými procesory) a logikou správy výkonu. Při vyvažování zátěže se ví, jaké jsou aktuální potřeby a je možné dělat nějaké odhady týkající se blízké budoucnosti; proto dává smysl, že by se ten samý kód účastnil rozhodování, jaké procesorové prostředky by pro danou zátěž měly být k dispozici.

Na základě těchto myšlenek a dalších postřehů Morten Rasmussen zaslal návrh přepracovaného plánovače, ohleduplného ke spotřebe energie. Současný plánovač by byl rozdělen do dvou oddělených modulů:

1. Plánovač CPU, který bude mít za úkol co nejlépe využívat dostupné procesorové prostředky.
2. „Plánovač výkonu“, který bude mít za úkol upravovat aktuálně dostupné prostředky CPU, aby odpovídaly zátěži vykazované plánovačem CPU.

Plánovač CPU bude řešit plánování jako doposud. Plánovač výkonu si zase bude brát informace o zátěži od plánovače CPU a podle potřeb bude měnit nastavení výkonu systému tak, aby to lépe odpovídalo této zátěži. Mezi tyto změny může patřit přesun CPU mezi stavy výkonu [power state] nebo uspání (nebo probuzení) CPU. Plánovač výkonu by komunikoval se současnými ovladači pro správu frekvence, ale tyto ovladače by nadále byly oddělené a specifické pro konkrétní hardware. Při tomto návrhu by vyvažování zátěže zůstalo pod kontrolou plánovače CPU; k přesunu do plánovače výkonu by nedošlo.

Zajisté je tu spousta problémů, které je nutné vyřešit mimo jednoduchou implementaci plánovače výkonu a definice rozhraní k plánovači CPU. Plánovač CPU nadále musí získat schopnost používat procesory s různými výpočetními schopnostmi; je to nutné pro architekturu big.LITTLE, ale i pro pokročilejší správu stavů výkonu. Aktuálně se procesům započítává, kolik času stráví během na CPU; to jednoznačně není fér vůči procesům spouštěným na pomalejším procesoru. Proto bude nutné používat jinou jednotku než čas, například počet instrukcí. Plánovač CPU si bude muset být vědom uplatňované politiky správy výkonu. Plánování procesů tak, aby byl využit režim „turbo boost“ (kdy je možné přetaktovat jediné CPU za předpokladu, že ostatní CPU jsou nečinná), zůstává otevřenou otázkou. Teplotní omezení přidávají do rovnice další proměnné. A tak dále.

Je také možné, že se oddělení plánování CPU a výkonů nepovede; Morten to popsal takto:

Jsem si vědom, že rozhodování plánovače a plánovače výkonu nemusí být oddělitelné, takže se možná rozhodneme je sloučit. I tak si myslím, že stojí za to snažit se oddělit rozhodování o výkonu od plánovače, leda by se ukázalo, že to jinak nejde.

I s těmito nejistotami se zdá přístup používající „plánovač výkonu“ jako dobrý začátek; Morten a jeho kolegové mají v plánu v brzké budoucnosti zaslat prvotní implementaci plánovače výkonu. Pak se snad od Inga dozvíme, jak dobře tento návrh splňuje požadavky; on (stejně jako ostatní vývojáři plánovače) se od posledních debat drželi stranou. Tak či tak to vypadá, že komunita bude na novém plánovači pracovat docela dlouho.

       

Komentáře

[filbar]

Nejsou verze jádra 3.9.4 a 3.9.6 ve stabilních aktualizacích prohozené? Proč by se připravovalo jádro 3.9.4 když už je 3.9.6 vydané?

[Nechápavec]

Protože je původní článek z 20.6. Tzn. asi 3 týdny starý. Nikdy jsem nepochopil, proč se u jaderných novinek tyto informace objevují, protože akorát matou. Já už je delší dobu ignoruju.

[filbar]

To vím, ale myslím, že přímo v tom odstavci se o tom píše jako o vydaném.

[stativ]

Mě to vyhovuje, protože si pak snadno můžu dát dohromady obsah novinek s verzemi jádra, pro které byly aktuální.

[Michal Kubeček]

Jenže tady je to zcela určitě špatně:

… dne 13. června vydal stabilní jádra 3.9.6, … Jádra 3.9.4, … se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté …

Reality check: 3.9.4 vyšlo 24. května, 3.9.6 13. června a 3.9.7 20. června. Takže místo 3.9.4 má být 3.9.7.

[2X4B-523P]

zvláštní, mě to vychází podle TOHOTO v pořádku, jaký je ten jiný zdroj?

[2X4B-523P]

beru zpět, špatně jsem pochopil v čem měla být chyba

[alkoholik]

S big.LITTLE bude jeste sranda.

[Petr Ježek]

Mám desítkové jádro, funguje bezvadně - není divu při aktivitě archtesterů :)