Portál AbcLinuxu, 10. května 2025 12:12
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.
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.
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.).
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
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.
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ý.
14.11.2012 09:48
Conscript89
| Brno
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...
14.11.2012 13:32
Jendа | skóre: 78
| blog: Jenda
| JO70FB
12.11.2012 22:41
David Heidelberg | skóre: 46
| blog: blog_
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
14.11.2012 10:43