Jaderné noviny – 29. 9. 2011: Oportunistické uspávání

10. 10. 2011 | Luboš Doležel | Jaderné noviny | 3509×

Aktuální verze jádra: 3.1-rc8. Citáty týdne: Glauber Costa, Linus Walleij, Brett Rudley. Stav kernel.org. Stěhování lesů. Nový přístup k oportunistickému uspávání.

Obsah

• Aktuální verze jádra: 3.1-rc8
• Citáty týdne: Glauber Costa, Linus Walleij, Brett Rudley
• Stav kernel.org
• Stěhování lesů
• Nový přístup k oportunistickému uspávání

Aktuální verze jádra: 3.1-rc8

Aktuální verze jádra je 3.1-rc8 vydaná 27. září. Diffstat je opravdu drobný, vyčnívají jen patche v coretemp a clock_ops spolu s drobnou aktualizací perf-tool, vše ostatní jsou v podstatě jen jedno nebo několikařádkové změny. A ani těch není mnoho. Samotné vydání 3.1 ještě tak týden potrvá kvůli problémům s kernel.org, ale jinak jádro vypadá, že je skoro připravené.

3.1-rc7 vyšlo 21. září, jen pár mikrosekund po vydání Jaderných novin. Linus k tomu řekl:

Začíná být jasné, že konečnou verzi 3.1 nevydám dřív než po mé dovolené začátkem října – jinak by příští začleňovací okno byl naprostý chaos. Začleňovací okno s kernel.org mimo provoz by prostě nešlo a vydávat verzi a na to hned mít chaotické začleňovací okno následované cestováním se zdá být šílené.

Mimo jiné to znamená, že se příští začleňovací okno může překrývat s Kernel Summitem, což by samo o sobě mohlo být šílené.

Stabilní aktualizace: během posledního týdne žádné nevyšly.

Citáty týdne: Glauber Costa, Linus Walleij, Brett Rudley

Protože už jsem kvůli tomu poslal RFC, tak teď posílám RFD. Pokud vás zajímá význam, tak by to mohl být „Request for Doctors“ [Žádost o doktory], neboť Peteru [Zijlstrovi] teď asi hrozí srdeční infarkt.

-- Glauber Costa

Zde je příklad PGA (Pin Grid Array) čipu zespodu:

        A   B   C   D   E   F   G   H
      +---+
   8  | o | o   o   o   o   o   o   o
      |   |
   7  | o | o   o   o   o   o   o   o
      |   |
   6  | o | o   o   o   o   o   o   o
      +---+---+
   5  | o | o | o   o   o   o   o   o
      +---+---+               +---+
   4    o   o   o   o   o   o | o | o
                              |   |
   3    o   o   o   o   o   o | o | o
                              |   |
   2    o   o   o   o   o   o | o | o
      +-------+-------+-------+---+---+
   1  | o   o | o   o | o   o | o | o |
      +-------+-------+-------+---+---+

Toto není tetris. Z her bychom mohli uvažovat o šachách.

-- pinmuxoví pěšci Linuse Walleije

Strávili jsme rok snahou být dobrými linuxovými obyvateli, předvedli jsme počáteční plány, dodržovali jsme pravidla, pracovali jsme transparentně, brali jsme ohled na zpětnou vazbu, přede všemi jsme zasílali stovky patchů a teď se nás lidi ptají, co je naším plánem. Naším plánem je dostat brcmsmac a brcmfmac do hlavní řady a následně přicházet s novými funkcemi, novými čipy a neutuchající podporou.

-- Brett Rudley

Stav kernel.org

Vývojáři pracující na obnově kernel.org zaslali krátkou zprávu o stavu věcí, především o správě gitových stromů. Tato nová infrastruktura už nebude nabízet shellový přístup ke gitovým repozitářům; namísto toho se bude používat git s webovým napojením gitolite. Gitolite používá pro push ssh klíče, takže začneme aktivním vývojářům, kteří předtím měli na kernel.org účet, posílat nové údaje pro ssh.

Stěhování lesů

V době psaní tohoto textu je kernel.org stále offline, ačkoliv se doufá, že alespoň přístup k gitovým stromům bude brzo obnoven. V Linusových plánech se zdá být otevření začleňovacího okna před polovinou října; bez funkčního kernel.org to nepůjde zdaleka tak lehce, jak by si komunita přála. Tak či tak nelze některé věci uspěchat a je důležité, aby se kernel.org vrátilo v solidním a bezpečném stavu.

Mezitím si řada stromů našla nový domov. Zde je aktualizovaný seznam přestěhovaných stromů:

ACPI	https://github.com/lenb/linux.git
ALSA	git://github.com/tiwai/sound.git
ALSA driver	git://github.com/tiwai/alsa-driver-build.git
ALSA SOC	git://opensource.wolfsonmicro.com/linux-2.6-asoc.git
amd64 EDAC	git://amd64.org/linux/bp.git
APM	git://twin.jikos.cz/jikos/apm
arm-soc	git://git.linaro.org/people/arnd/arm-soc.git
DRM	git://people.freedesktop.org/~airlied/linux
fbdev	https://github.com/schandinat/linux-2.6
HID	git://twin.jikos.cz/jikos/hid
hwspinlock	git://github.com/ohadbc/hwspinlock-next.git
infiniband	https://github.com/rolandd/infiniband
input	https://github.com/dtor/input
ipvs	git://github.com/horms/ipvs.git
kbuild	http://repo.or.cz/w/linux-kbuild.git
kvm	git://github.com/avikivity/kvm.git
libata	git://github.com/jgarzik/libata-dev.git
linux-next	git://github.com/sfrothwell/linux-next.git
mainline	git://github.com/torvalds/linux.git
mmc	git://dev.laptop.org/users/cjb/mmc mmc-next
networking	git://github.com/davem330/net
pm	git://github.com/rjwysocki/linux-pm.git
regmap	git://opensource.wolfsonmicro.com/regmap.git
SCSI	git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6.git git://bedivere.hansenpartnership.com/git/scsi-misc-2.6.git
slab	git://github.com/penberg/linux.git
tip	git://tesla.tglx.de/git/linux-2.6-tip
tmem	git://oss.oracle.com/git/djm/tmem.git
trivial	git://twin.jikos.cz/jikos/trivial
utrace	git://github.com/utrace/linux.git
v9fs	git://github.com/ericvh/linux.git
wireless	git://git.infradead.org/users/linville/wireless.git git://git.infradead.org/users/linville/wireless-next.git git://git.infradead.org/users/linville/wireless-testing.git
xen	git://oss.oracle.com/git/kwilk/xen.git

Tento seznam přesunutých stromů je dost velký, avšak, jak správce linux-next Stephen Rothwell poznamenal 27. září, stále zbývá 89 stromů, které jsou jen na kernel.org. Tyto stromy od výpadku kernel.org nezaznamenaly žádné aktualizace. Některé z nich jsou určitě nečinné nebo k tomu mají blízko; ne každý strom, který dodává obsah pro linux-next, má patche v každém vývojovém cyklu. Ale existence ostatních má jistě důvod; pokud se kernel.org nevrátí brzo, budou si muset najít nový domov.

Jedním významným stromem, který se zatím nepřesunul, je strom stabilních vydání; poslední stabilní aktualizace vyšla 29. srpna.

S trochou štěstí se kernel.org brzo vrátí a tento seznam bude nepotřebný. Ale až se kernel.org vrátí, může vypadat poněkud jinak. Už bylo oznámeno, že ke strojům s gitovými stromy nebude shellový přístup. Můžou být zavedena i jiná bezpečnostní opatření, některé z nich mohou znamenat změny pro to, jak vývojáři pracují. Udělání takových změn v čase, který zbývá do dalšího začleňovacího okna, může být obtížné. Jinými slovy, vývojový cyklus 3.2 může být o něco zajímavější a méně plynulý.

Nový přístup k oportunistickému uspávání

"Oportunistické uspávání" je technika správy výkonu používaná na zařízeních s Androidem. Namísto snahy uvést různé částí systému do režimu nízké spotřeby funguje oportunistické uspávání tak, že prostě uspí celé zařízení, jakmile je zjištěno, že se neděje nic zajímavého. Takto spravovat spotřebu energie je kontroverzní, ale skutečným problémem je detekce toho, zda je dobrý čas se uspat. Androidí mechanismus pro řízení oportunistického uspávání byl nazván „probouzecí zámky“ [wakelocks] nebo „blokátory uspání“ [suspend blockers]; tak či tak to vždycky znamenalo klikatou cestu, jakmile se objevily pokusy začlenit tuto věc do jádra. John Stultz navrhl alternativu k blokátorům uspání, která má stejné problémy jisté, ale je každopádně zajímavé se na to podívat.

Blokátory uspání jsou způsobem, jak jádro nebo uživatelský prostor řeknou systému, že není správný čas se uspat; použití blokátorů z uživatelského prostoru je privilegovaná operace. Aby to fungovalo správně, blokátory uspání musejí být podporovány každým zařízením, které může probudit systém. Ovladače pro taková zařízení vytvoří blokátor uspání, kdykoliv dojde k probuzení, a probudí jakýkoliv proces z uživatelského prostoru, který na událost čeká; jakmile proces přečte událost, blokátor bude uvolněn. Klíčem je to, že daný proces z uživatelského prostoru, pokud má dostatečná oprávnění, může získat svůj vlastní blokátor, než přečte událost, která jej probudila. Překryv mezi získáním blokátoru v uživatelském prostoru a uvolnění toho v jádře umožňuje spolehlivé probouzení systému, aniž by bylo riskováno uspání dříve, než je událost zpracována.

Jednou z věcí, které se Johnovi nelíbily na tomto mechanismu, bylo implicitní API blokátorů uspání mezi uživatelským prostorem a zařízeními, která mohou probouzet systém. Proto přišel s něčím trochu odlišným, i když jádro myšlenky zůstává stejné.

Celým smyslem blokátorů uspání je umožnit „důležitým“ procesům udržet zařízení probuzené, i když by si jinak mohlo vybrat, že se uspí. Proto se John zeptal, proč takové procesy prostě neoznačit? Jeho patch přidává do plánovače novou volbu:

sched_setscheduler(0, SCHED_STAYAWAKE, &param);

Jakmile je takto nějaký proces označen, jádro systém jednoduše neuspí. Toto platí, i když daný proces blokuje; jinak by disková I/O operace nebo výpadek stránky mohly stačit k uvedení do uspání v nevhodnou chvíli.

V životě to ale samozřejmě není tak snadné; existují situace, kdy je žádoucí systém uspat, i když existují nějaké „důležité“ procesy. Příkladem je situace, když důležitý proces blokuje na zařízení, které je samo o sobě schopno generovat probouzecí události. Umožnění uspání v takových situacích si žádá poladění relevantních ovladačů; v zásadě musí být podobný řádek:

sched_deboost_task_active_count(current);

přidán, aby byl odstraněn status „důležitosti“ aktuálního procesu dříve, než je dán povel k uspání. Jakmile toto zařízení probudí blokovaný proces, jeho speciální status mu je navrácen.

Jediným zbývajícím problém je opět to zabránit systému, aby se zase uspal, než proces získá svůj status zpět. Toto je ošetřeno přidáním volání __pm_stay_awake() a __pm_relax() kolem kódu, který probouzí blokované procesy. John také musel změnit kód uspávání tak, aby __pm_stay_awake() bylo o něco méně jako doporučení, než jak je to v současných jádrech. Jakmile to bylo hotové, tak už nehrozilo, že se zařízení uspí, než důležité procesy dostanou šanci získat zpátky svůj status.

V době psaní tohoto textu byla jedinou zpětnou vazbou na tuto sadu patchů reakce od správce plánovače Petera Zijlstry. Postačí říct, že se mu to nelíbilo. Podle Petra je oportunistické uspávání snahou zakrýt problém, který by měl být vyřešen v uživatelském prostoru; řekl, že nedůležité procesy by v první řadě neměly běžet vůbec. Tento pohled na druhou stranu asi nebude moc oblíbený mezi lidmi od Androidu. Takže ačkoliv Johnovo přístup zjednodušuje myšlenku probouzecích zámků, nezdá se být pravděpodobné, že by uzavřel debatu kolem tohoto přístupu ke správě výkonu.

       

Komentáře

[pc2005]

Citáty jsou dneska nemálo vypečené .

[misacek]

Tak, tak

[dšfľ]

By ma zaujimalo, kolko ludi pracuje na pozbierani kernel.org. Ak sa nemylim, od toho incidentu ubehli uz asi dva tyzdne. Za dva tyzdne fulltime prace som si ja (linux pokrocili user) nahodil gentoo do pouzitelneho stavu na desktope, vratane krusadera, mpd a nastavenia klavesovych skratiek vo fluxboxe! A verim tomu, ze skileri by LFS nahodili na server pod 16 hodin... Co tolko zbieraju na tom serveri? Nespominali, ze to cele reinstaluju a bude? Je tam tak malo ludi/casu, ktory sa tomu venuje, alebo sa tak velmi zameriavaju na bezpecnost a kontroluju kazdy nainstalovany sw rucne?

[Filip Jirsák]

Instalace serveru je myslím ta nejméně náročná část. Podstatné je obnovit data, dát k nim přístup pokud možno v původním rozsahu, a zároveň zabránit opakování problémů.

[Kaacz]

Aha, reakce clovek ktery neni plne v obraze.

Vubec nejde o reinstalaci serveru, to zvladne cvicena opicka. Pokud nekdo nekde napsal, ze cela cela vec se vyresi jen reinstalaci serveru, tak je tu hlupak nebo lhar.

Strasne pracne a zdlouhave je sestavit zpet komplet data s kontrolou, jestli nebyla modifikovana po pruniku. A ze to je pekna halda souboru.

[Kaacz]

Mne ty piny PGA pripominaji spis "Lode"

[alkoholik]

Lode?

[Pindal]

Tipuju, že místo potopeno se hlásí vypito