Jaderné noviny – 9. 2. 2012: Automatické uspávání

20. 2. 2012 | Luboš Doležel | Jaderné noviny | 3622×

Aktuální verze jádra: 3.3-rc2. Citáty týdne: Greg Kroah-Hartman, Andrew Morton, Tony Luck, Anton Altaparmakov. Intel přijde s transakční pamětí. POHMELFS se vrací. Automatické uspávání a probouzecí zámky.

Obsah

• Aktuální verze jádra: 3.3-rc2
• Citáty týdne: Greg Kroah-Hartman, Andrew Morton, Tony Luck, Anton Altaparmakov
• Intel přijde s transakční pamětí
• POHMELFS se vrací
• Automatické uspávání a probouzecí zámky

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

Aktuální vývojová verze jádra je nadále 3.3-rc2; během uplynulého týdne žádné předverze v řadě 3.3 nevyšly.

Se stabilními aktualizacemi je to trochu složitější. Verze 2.6.32.56, 3.0.19 a 3.2.3 vyšly 3. února se dlouhým seznamem patchů. Verze 3.2.4 následovala krátce poté kvůli chybě při sestavování, která byla zanesena do verze 3.2.3.

6. února vyšly verze 3.0.20 a 3.2.5. V těchto aktualizacích šlo jen o jeden patch, který opravoval problém související s ASPM, jenž by na některých systémech značně zvýšil spotřebu energie. Tomuto patchi bylo věnováno jen omezené množství péče; vypadá to, že funguje, ale nikdo neví, zda nemůže na nějakém obskurním hardwaru způsobit problémy s chováním. Tak či tak ale vypadal dostatečně bezpečně na to, aby se dostal do stabilní aktualizace.

Citáty týdne: Greg Kroah-Hartman, Andrew Morton, Tony Luck, Anton Altaparmakov

Upozorňuji, že jsem současně odstranil i řádek v souboru unusedcode.easy, pokud jsem to neměl udělat, tak mi dejte vědět a patch předělám.

Pokud jsem něco pokazil nebo je k patchi třeba víc informací v seznamu změn, dejte mi vědět a napravím to.

-- Greg Kroah-Hartman se stal vývojářem LibreOffice

Pokud chceme opravdu vylepšit svět, měli bychom skočit do stroje času a nastavit tabstop na 4.

-- Andrew Morton

10? Máme tu několik proměnných s délkou přes 100 znaků (nevím, jak s nimi máte pracovat při maximální délce řádku 80 znaků). Současná nejdelší je:

eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters

se 104 znaky.

-- Tony Luck (vizte include/linux/netfilter/nf_conntrack_h323_types.h)

V jádře 3.1 Cristoph odstranil i_alloc_sem a nahradil je voláními (jmenovitě inode_dio_wait() a inode_dio_done()), která jsou pod EXPORT_SYMBOL_GPL(), a proto nemohou být používána souborovými systémy, co nejsou pod GPL, navíc bylo inode_dio_wait() přesunuto z notify_change() do metody ->setattr() souborového systému, ale žádný ne-GPL souborový systém toto volání nemůže udělat.

To znamená, že souborové systémy, co nejsou pod GPL, nemohou existovat, leda by nepoužívaly žádnou funkčnost VFS kolem čtení a zápisu nebo dokud chtějí implementovat přímé I/O.

Co teď mají komerční souborové systémy dělat?

-- Anton Altaparmakov

Intel přijde s transakční pamětí

Zde naleznete text na Intel software network, kde je popisována funkčnost „rozšíření pro transakční synchronizaci“, která bude v budoucích procesorech „Haswell“.

S transakční synchronizací může hardware dynamicky dělat rozhodnutí, zda musejí být vlákna serializována přes zámkem chráněné kritické sekce, a dělat serializaci, jen pokud je to nutné. Toto umožňuje procesoru vystavovat a využívat concurrency, které by jinak bylo skryté kvůli dynamicky nepotřebné synchronizaci. Na nejnižších úrovních jsou programátorem určené oblasti kódu (také označované jako transakční oblasti) pomocí Intel TSX spouštěny transakčně. Pokud je transakční spuštění dokončeno úspěšně, pak se všechny paměťové operace vykonané v rámci transakční oblasti z pohledu ostatních logických procesorů zdánlivě objeví okamžitě. Procesor zviditelňuje aktualizace vykonané v rámci oblasti ostatním logickým procesorům pouze při úspěšném commitu, což je proces označovaný jako atomický commit.

Není snad ani potřeba dodávat, že by tuto funkci šlo zajímavě využít v jádře, pokud bude fungovat dobře, ale i jiné projekty (například PyPy) rovněž projevily o transakční paměť zájem.

POHMELFS se vrací

Na LWN se o POHMELFS zběžně psalo začátkem roku 2008; od té doby se POHMELFS povaloval ve staging stromu, aniž by se mu někdo moc věnoval nebo se o něj zajímal. Vývojář POHMELFS Evgeniy Polyakov vyjádřil svou nespokojenost s vývojovým procesem a z jaderné komunity na nějaký čas zmizel.

Teď se ale Evgeniy vrátil a hned s novou verzí. Napsal k tomu:

Od paralelního návrhu NFS, který přežíval v drivers/staging/pohmelfs roky bez rozumného využití, urazil kus cesty – tento návrh byl mrtvý.

Nový pohmelfs využívá eliptickou síť jako úložiště, ukázalo se to jako efektivní distribuovaný systém. Eliptika je produkčně používána ve vyhledávací společnosti Yandex už několik let a dobře škáluje (od 6 nodů v 3 datacentrech pro hostování 15 miliard malých souborů po stovky nodů s 1 PB dat pro streamování).

Tentokrát by chtěl zařazení souborového systému přímo do hlavní řady bez mezizastávky ve staging stromu. Jenže začleňování souborových systémů je bez posudků za strany správců VFS těžké a zatím to ještě nikdo nezhlédl. Takže Evgeniy si asi bude muset počkat.

Automatické uspávání a probouzecí zámky

Významnou událostí prosince roku 2011 bylo oznámení projektu začleňování Androidu a návrat řady ovladačů z Androidu do staging stromu. Ta nejkontroverznější odlišnost Androidu – probouzecí zámky [wake locks] nebo blokátory uspání [suspend blockers] – součástí tohoto úsilí ale nejsou. Tento kód je dostatečně intruzivní a dostatečně kontroverzní na to, aby se k tomu nechtěl nikdo vracet. Jenže jak to tak vypadá, někdo se o to přesto snaží. Sada patchů pro automatické uspávání a probouzecí zámky od Rafaela Wysockého je dalším pokusem o podporu oportunistického uspávacího mechanismu z Androidu v hlavní řadě jádra.

"Oportunistické uspávání" je drsný přístup ke správě výkonu. Ve zkratce jde o to, že když se neděje nic zajímavého, tak se celý systém prostě uspí. Na zařízeních s Androidem to je nepochybně efektivní; zejména to brání mizerně napsaným aplikacím v tom, aby udržovaly systém vzhůru a vysávaly baterii. Obtížnější částí je rozhodování, zda se opravdu neděje nic zajímavého; to má za úkol androidí mechanismus s probouzecími zámky/blokátory uspání. S blokátory uspání jaderný i vhodně privilegovaný kód v uživatelském prostoru mohou zablokovat běžné uspávání systému a udržet jej vzhůru, ať už potřebují udělat cokoliv.

Vzhledem k tomu, že se blokátory uspání do hlavní řady jádra asi brzy nedostanou, je nutné zavést alternativní mechanismus, aby bylo oportunistické uspávání umožněno. Čistě náhodou už nějakou chvíli dílky nezbytné skládačky v jádře jsou; infrastruktura probouzecích událostí [wakeup events] byla začleněna ve verzi 2.6.36. Probouzecí události sledují události (například stisk tlačítka), které mohou systém probudit nebo jej udržet vzhůru. „Zdroje probouzení“, které sledují zdroje probouzecích událostí, byly začleněny v jádře 2.6.37. Zatím je ale tento subsystém používán dost málo; jen málo ovladačů ve skutečnosti posílá takové události. Zdroje probouzení nejsou skoro vůbec používány.

Rafaelův patch dělá velké změny, které používají tuto infrastrukturu pro podporu „automatického uspávání“, což je jen jiný obrat pro „oportunistické uspávání“. (Rafael říká: Tyto patche slouží k ověření teorie, že nejsnazším způsobem, jak udat funkci, která už byla jednou odmítnuta, je představit ji pod jiným názvem.) První přidanou věcí je nový soubor v sysfs nazvaný /sys/power/autosleep; zapsání „mem“ do tohoto souboru způsobí uspání systému, kdykoliv není žádný zdroj probouzení aktivní. Je možné napsat i „disk“, což způsobí oportunistickou hibernaci; tato funkce asi nenajde zrovna moc využití, ale bylo snadné ji přidat.

Android sleduje, jak dlouho blokátory uspání brání uspání systému; tato informace je zobrazována na obrazovce „Využití baterie“. Rafaelův patch přidává podobnou sledovací funkci a tento čas zveřejňuje (jako prevent_sleep_time) v /sys/kernel/debug/wakeup_sources.

Je tu ale jeden malý problém: zdroje probouzení jsou dobré pro sledování událostí s původem v jádře, ale uživatelskému prostoru nedávají žádný způsob, jak dát najevo, že by systém neměl být uspán. Zjevně je nutné přidat mechanismus, pomocí kterého by uživatelský prostor mohl vytvářet vlastní zdroje probouzení. Poslední patch v Rafaelově řadě právě toto přidává. Aplikace může zapsat název (a volitelně i časový limit) do /sys/power/wake_lock pro vytvoření nového, aktivního zdroje probouzení. Tento zdroj zabrání systému v uspání, dokud neuběhne časový limit nebo dokud není stejné jméno zapsáno do /sys/power/wake_unlock.

Je na první pohled vidět, že tento mechanismus může být použit k implementaci androidího oportunistického uspávání. Ovladač, který obdrží probouzecí událost, označí související zdroj probouzení jako aktivní, což udrží systém vzhůru. Tento zdroj zůstane aktivní, dokud uživatelský prostor tuto událost nevyčerpá. Ale ještě než se tak stane, aplikace v uživatelském prostoru získá svůj vlastní „probouzecí zámek“, čímž zajistí, že bude moci dokončit svou práci, než se systém zase uspí.

Ti z vás, kteří pozorněji sledovali celou kontroverzi kolem této funkčnosti, si jistě všimnou, že API pro tuto funkčnost je nápadně podobné nativnímu androidímu API. Samozřejmě to není náhoda; smyslem je co nejvíce usnadnit přechod na nový mechanismus, aniž by androidí systémy byly tímto nějak porouchány. Pokud se toho podaří dosáhnout, tak i kdyby samotný Android na tuto implementaci nikdy nepřešel, mělo by být mnohem snazší provozovat uživatelský prostor Androidu na jádře hlavní řady.

A to je samozřejmě nejsilnější možný argument pro tuto sadu patchů. Pokud se někomu podaří předvést androidí systém s nativním oportunistickým uspáváním, který bude mít spotřebu energie podobnou originálu, tak bude mnohem pravděpodobnější, že se tomuto patchi podaří uspět, i když ostatní selhali. Nebude úplně snadné připravit takovou předváděčku, ale na vhodném hardwaru to samozřejmě půjde. Jako dobrý základ může posloužit postup od Linara. Než se to někomu povede, tak bude asi trochu problém do jádra oportunistické uspávání kompatibilní s Androidem dostat.

       

Komentáře

[Mustafa]

Čtu tam nahoře u citátů, že Greg Kroah-Hartman se stal vývojářem LibreOffice.

To už se jádru věnovat nebude? Není to nějaká chyba v článku?

[Luboš Doležel (Doli)]

To už se jádru věnovat nebude? Není to nějaká chyba v článku?

To je myšleno jako humor Pomohl LibreOffice akorát tím, že zlikvidoval nějaký přebytečný kód (kterého tam mají až až).

[jc]

Myslim ze jednoduchym zahazovanim nepotrebneho kodu by se neobtezoval. Pise, ze TAKE zrusil jeden radek v unusedcode.easy.

[Luboš Doležel (Doli)]

Pise, ze TAKE zrusil jeden radek v unusedcode.easy.

A jak se to vylučuje s tím, co píšu? Smazal nepotřebný kód a odstranil ho ze seznamu nepoužívaného kódu.

Myslim ze jednoduchym zahazovanim nepotrebneho kodu by se neobtezoval.

Uff

[Gilhad]

Zdroje probouzení jsou nejsou skoro vůbec používány. (vyberte si po libosti)

Android sleduje, kal dlouho blokátory (jak-ze?)

[Luboš Doležel (Doli)]

Díky, opraveno.

[deda.jabko]

Máme tu několik proměnných s délkou přes 100 znaků (nevím, jak s nimi máte pracovat při maximální délce řádku 80 znaků). Současná nejdelší je: eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters se 104 znaky.

pripomelo mi to legendarni kod noveho hlodace. :-]]

[clayman]

Borce asi baví psát...

[Jakub Lucký]

ve Wordpadu...

[tomo_tn]

A to som mal obcas pocit ze pouzivam dlhe premenne :)

Popravde snazim sa vyzit z 1 -- 3 slovami aby som sa v kode vedel zorientovat aj po dlhsej dobe ale pritom bol stale udrzatelny.

[Tyf]

Vim, co je autor za podivny zivel.

Ale ma plus, ze vi, jaky je anglicky plural od slova "index." A druhe plus, ze do ukazky pro obeti/investory nedal vubec nic.

[snajpa]

Evgeniy te DHT ulozne siti rika The Elliptics - prekladat to jako Eliptika asi neni uplne cele-vpravo :)

[snajpa]

Ale jinak bych mel rict, ze ja se ozvu akorat, kdyz se mi neco nelibi vetsinou... Takze abych jenom nenadaval: diky za JN, ctu pravidelne a jsem za ne rad!

[Luboš Doležel (Doli)]

Já vůbec netuším, jak toto přeložit. Rád to nahradím lepším překladem.

[snajpa]

Nijak, je to nazev :)

[Jindřich Makovička]

Možná by se hodil odkaz na http://ioremap.net/projects/elliptics