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

12. 11. 2012 | Luboš Doležel | Jaderné noviny | 3259×

Aktuální verze jádra: 3.7-rc2. Citáty týdne: Rob Pike, Andrew Morton, Jiří Slabý, Dave Airlie. Zdrojový kód ovladače VideoCore pro Raspberry Pi uvolněn. Shlukování drobných úloh.

Obsah

• Aktuální verze jádra: 3.7-rc2
• Citáty týdne: Rob Pike, Andrew Morton, Jiří Slabý, Dave Airlie
• Zdrojový kód ovladače VideoCore pro Raspberry Pi uvolněn
• Shlukování drobných úloh

Aktuální verze jádra: 3.7-rc2

Akuální vývojová verze jádra je 3.7-rc2 vydaná 20. řína. Linus k tomu řekl:

Asi tak po týdnu tu máme -rc2. Nejvýraznější věcí je asi opravování důsledků změn – najdete tu spousty patchů pro dokončení (a opravení následků) reorganizace hlavičkových souborů UAPI, ale další změny se třeba týkají toho, jak jsou podepisovány moduly atd. atd.

Stabilní aktualizace: verze 3.0.47, 3.4.15 a 3.6.3 byly vydány 21. října; každá z verzí obsahuje důležité opravy. Verze 3.4.15 a 3.6.3 také obsahují chybu poškozující data na ext4 (stejně jako jejich předchůdci a 3.5.7), takže je lepší počkat na další aktualizaci. Verze 3.0.47 pak zase obsahuje patch blokového subsystému, který by mohl způsobit problémy; ve verzi 3.0.48 vyšel revert.

18. října mezitím vyšla verze 3.2.32.

Citáty týdne: Rob Pike, Andrew Morton, Jiří Slabý, Dave Airlie

Když jsem jel na Plan 9, všechno bylo propojené a jednotné. Teď není propojené všechno, je to jen připojené do cloudu, což není to samé. A jednotné? Kdeže, leda ve své průměrnosti. Je rok 2012 a nadále propojujeme malé mikropočítače pomocí HTTPS a ssh a říkáme tomu revoluce. Hodně mi schází jednotný systémový pohled na svět, který jsme měli v Bell Labs, a podle toho, jak to vypadá teď, se to jen tak nevrátí.

-- Rob Pike

local_irq_save() a local_irq_restore() byly chybou :( Je hloupé napsat něco, co vypadá jako céčková funkce a pak to nechat fungovat jako Pascal (pozor: naposledy jsem v Pascalu něco psal v roce 66 př. Kr.).

-- Andrew Morton

A je to tu. Ten velký krok, na kterém jsme v posledních verzích jádra pracovali. Teď už je všechno nachystané, takže nám nic nebrání v tom tento velký krok udělat.

           |  |            \  \ nnnn/^l      |  |
           |  |             \  /     /       |  |
           |  '-,.__   =>    \/   ,-`    =>  |  '-,.__
           | O __.´´)        (  .`           | O __.´´)
            ~~~   ~~          ``              ~~~   ~~

-- Jiří Slabý

Takže Raspberry Pi a Broadcom si zaslouží mít máslo na hlavě, že se vůbec obtěžovali kvůli tomuhle vydávat tiskovou zprávu, kdyby jen zveřejnili kód a jeli v klidu dál, tak by všechno bylo v pohodě, nikomu by nic nescházelo, ale nějaký idiot si myslel, že si tadyta mrzká vata zaslouží tiskovou zprávu, blbost.

-- Dave Airlie

Zdrojový kód ovladače VideoCore pro Raspberry Pi uvolněn

K předchozímu citátu se vztahuje oznámení Raspberry Pi Foundation o uvolnění zdrojového kódu grafického ovladače pod licencí BSD. Pokud nejste obeznámeni se stavem open source ovladačů na ARM SoC, tak vám toto oznámení nemusí připadat jako něco revolučního, ale jde o to, že BCM2835 používané v Raspberry Pi je prvním multimediálním ARM SoC s plně funčními plně open source ovladači od výrobce (nikoliv s původem ve zpětném inženýrství) a Broadcom je prvním výrobcem, který takto otevřel své mobilní ovladače GPU.

Shlukování drobných úloh

Linuxový plánovač byl ve svých nejrůznějších podobách vždy optimalizován na (mnohdy protichůdné) cíle maximální propustnosti a interaktivity. Vyvažování těchto dvou požadavků napříč různými typy zátěže se za ta léta ukázalo být dosti obtížným; dalo by se říci, že to poslední, co vývojáři plánovače potřebují, je další problém navrch. To je ale právě to, co se v poslední době stalo: od plánovače se teď navíc očekává ještě to, že bude minimalizovat spotřebu energie. Ať už jde o systém ve vaší kapse nebo v obrovském datovém centru, jeho vlastníkovi jistě záleží na tom, aby byl energeticky efektivnější. Tento problém je těžké vyřešit, ale Vincent Guittot nedávno zaslal patch pro shlukování drobných úloh, který může být tím správným krokem.

"Drobná úloha" je v tomto kontextu něco, co používá relativně málo času CPU; drobné úlohy jsou zejména aktivní (runnable) méně než 25 % času. Pokud jsou tyto úlohy rozprostřeny napříč systémem s vícero CPU, může to způsobovat, že tyto procesory budou drženy vzhůru, aniž by byly významně zatěžovány. Místo živení všech těchto CPU dává jednoznačně smysl tyto drobné úlohy shlukovat na menším počtu procesorů a umožnit těm zbylým se vypnout.

Prvním krokem je pochopitelně dokázat tyto drobné úlohy identifikovat. To může být složitější: v současných jádrech plánovač neshromažďuje údaje potřebné pro takové rozhodování. Dobrá zpráva je to, že tento problém už byl vyřešen Paulem Turnerem a jeho patchem pro sledování zátěže dle entit, který umožňuje náležité sledování zátěže přidané do systému každou z „entit“ (což je proces nebo řídící skupina plná procesů). Tento patch existuje už nějakou dobu mimo strom, ale v plánu je ho v blízké budoucnosti určitě začlenit.

Jaderný mechanismus plánovacích domén představuje topologii systému ukrytého pod ním; mimo jiné má pomoci plánovači se rozhodovat, kdy má smysl přesunout proces z jednoho CPU na druhé. Vincentův patch začíná tak, že přidává příznak určující, kdy dvě CPU (nebo skupina CPU na vyšší vrstvě) sdílejí jeden zdroj energie. V takovém případě nelze tato CPU vypínat nezávisle. Ve výchozím stavu je tento příznak nastaven u všech CPU; to zachovává dosavadní chování plánovače.

Skutečným cílem je z pohledu správy energie uvolnit všechna CPU na daném zdroji energie, aby celá tato skupina mohla být vypnuta. Jak jsme nedávno viděli, kód pro migraci procesů musí být napsán opatrně, aby neměl dopad na výkon plánovače jako celku. Proto je obzvláště důležité, aby plánovač nemusel procházet celý (potenciálně dlouhý) seznam CPU při zvažování, zda by drobná úloha měla být přesunuta, nebo ne. Proto Vincentův patch dává při inicializaci systému každému CPU „kamaráda“. „Kamarád“ není úplně nejlepší termín, protože vztah je v tomto případě jednostranný; CPU může přesunout své drobné úlohy na svého kamaráda (a jen na něj), ale kamarád mu to nemůže oplatit.

Představme si jednoduchý systém o čtyřech CPU ve dvou soketech, který vypadá takto:

U každého CPU se plánovač snaží najít pro zkamarádění nejbližší vhodné CPU na odlišném zdroji energie. „Nejvhodnějším“ CPU je obvykle to s nejnižším číslem v dané skupině, ale na heterogenních systémech kód vybere CPU s nejnižší spotřebou energie na základě předpokladu, že jde o energeticky nejvýhodnější volbu. Pokud by tedy každé CPU a každý soket na ukázkovém systému mohly být vypínány nezávisle, přidělení přátel by vypadalo takto:

CPU 0 kamaráda nemá, protože to je CPU s nejnižším číslem v systému. Kdyby procesory 2 a 3 sdílely zdroj energie, rozdělení kamarádů by vypadalo trochu odlišně:

Vždy jde o to definovat snadnou cestu, pomocí které pak lze vybírat nezávislé CPU, kam se má přesunout drobná úloha.

Jakmile máme toto vyřešené, tak jsou změny v samotném plánovači docela malé. Obvyklý kód pro vyvažování zůstává nezměněn z toho důvodu, že drobné úlohy nebývají při vyvažování přesouvány, neboť je pravděpodobné, že zrovna spí. Místo toho plánovač při každém probuzení drobné úlohy bude zvažovat, zda by úloha měla být přesunuta z aktuálního CPU na kamarádské CPU. Pokud je cílové CPU dostatečně neaktivní, tak bude úloha přesunuta; jinak se situace ošetří běžným způsobem. Časem jsou drobné úlohy přesouvány směrem ke konci řetězce kamarádů, dokud nejsou tyto procesory příliš vytížené. Ve výsledku se tedy „shluknou“ na relativně malém počtu energeticky efektivních procesorů.

Vincentův patch obsahoval výsledky benchmarku, které ukazují, že propustnost upraveného plánovače je prakticky nezměněna. Spotřeba energie je něco docela jiného; při použití „cyclictest“ jako benchmarku byla spotřeba energie na třetinové úrovni. Při skutečné zátěži nebude přínos patche tak velký, ale je jasné, že přesun drobných úloh na menší počet procesorů může být užitečný.

       

Komentáře

[ertwertwe]

rob pike, software research is irrelevant:

http://doc.cat-v.org/bell_labs/utah2000/

[ertwertwe]

rozhovor s pikem:

http://rob.pike.usesthis.com/

The Blit - The first Unix graphical multi-programming terminal (1982) by Rob Pike and Bart Locanthi:

http://www.youtube.com/watch?v=emh22gT5e9k

[:::]

ten jeho "dream setup" je naprosto zcestnej. V podstate by si pral aby pocitac byla jenom obrazovka a vsechny data byly u velkyho bratra. Na to nikdo rozumnej nemuze pristoupit...

[Conscript89]

Necetl jsem si rozhovor, ale na tomto principu je staveny Chromebook a ten ma pomerne uspech, ne?

[pavlix]

Úspěch kde? Ve školství?

[avzgag]

rob pike netvrdi, ze ty data maji byt v cloudu, ale ze je zbytecne aby kazdy komp v siti (mysleno firemni) mel obludny harddisk s daty. lidi maji mit tenke klienty a ty pomoci protokolu 9P komunikuji s file serverem kde jsou data, nebo muze mit klient slaby vykon a muze pouzivat jiny komp s vetsim vykonem a pritom mit pomoci 9P pripojeny (import/export) vlastni filesystem takze uzivatel nepozna rozdil.

takze spise si prectete o principech plan9, protokolu 9P, vsechno je soubor....

[cronin]

Ach, kde sú tie staré zlaté časy, keď som pri odchode zo svojho pracovného miesta vytiahol kartu zo Sun Ray-a, strčil ju do iného vo vedľajšej kancelárii a po zadaní hesla sa objavil môj desktop so všetkým, ako som to u seba nechal. Fňuk.

[:::]

I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else's problem, one I'm happy to pay to have them solve.

Is he for real ??

Kdyz nad tim tak premyslim tak me napada - neplati ho nekdo za to aby tohle rikal? Protoze se me vazne nechce verit ze by tohle chtel...

[ertwertwe]

sice dneska pracuje v google, ale tahle veta je urcite jeste z obdobi tak 1990, pred jakymkoliv cloud boomem. ja si myslim, ze to byla tehdejsi pekne teoreticka predstava mit terminaly, samostatne cpu servery, samostatne file servery propojene pomoci 9P protokolu. to ma na mysli, ze plan9 je krasne propojen, zatimco my dnes propojujeme stanice pomoci http, ssh.

[Jendа]

A o šifrování, o šifrování jste už slyšeli?

[Michal Vyskočil]

Každá šifra jde triviálně zlomit, pokud je o to zájem.

[Jendа]

Pokud někdo má náladu na násilí, získat od uneseného ten pevný disk už asi nebude problém.

[David Heidelberg]

sice opensource wrapper okolo RPi gpu, ale otevřené ovladače si stejně komunita musí napsat sama (aneb blob v "opensource driveru" dělá všechno, skoro by se i dalo říct, že je to sám driver)