Jaderné noviny - 30. 1. 2008

14. 3. 2008 | Robert Krátký

Články - Jaderné noviny - 30. 1. 2008  

Aktuální verze jádra: 2.6.24. Citáty týdne: Andrew Morton, AntonBlanchardFacts.com. Co se dostalo do 2.6.25. Jak zabránit řádění OOM zabijáka pomocí mem_notify. API pro informaci o dokončení blokového I/O požadavku.

Obsah

• Aktuální verze jádra: 2.6.24
• Citáty týdne: Andrew Morton
• Co se dostalo do 2.6.25
• Jak zabránit řádění OOM zabijáka pomocí mem_notify
• API pro informaci o dokončení blokového I/O požadavku

Aktuální verze jádra: 2.6.24

Aktuální verze jádra je 2.6.24, vydaná 24. ledna. Za vyzdvižení stojí kontrolní skupiny (dříve kontejnery procesů), sjednocení architektur i386 a x86_64, skupinové plánování v CFS, jmenné prostory sítí a PID, jaderné značkovače [kernel markers], odstranění modulárního bezpečnostního rozhraní a mnohem více. Vizte seznam začleněných patchů nebo jako vždy úžasnou stránku o změnách na KernelNewbies.

Okno pro začleňování do 2.6.25 je otevřené, ale vybírání patchů pokračuje poměrně pomalu, protože se do něj plete linux.conf.au. Vizte kapitolku níže, kde najdete shrnutí věcí, které byly do této chvíle začleněny.

Starší jádra: 2.6.16.60 vyšlo 27. ledna s přibližně desítkou oprav.

Citáty týdne: Andrew Morton, AntonBlanchardFacts.com

Hodně těch patchů jsem prostě přeskočil, protože už mě nudilo opravování rejectů. Lidé dneska posílají patche aplikované na hlavní strom.

Budu pracovat na zprovoznění sjednoceného vývojového stromu: bude obsahovat nejčerstvější věci od všech lidí a denně bude aktualizován. Bude to v podstatě -mm bez pár narychlo spíchnutých stromů. Pak bude možné připravovat patche oproti tomuto novému stromu, protože to vypadá, že většina lidí se neobtěžuje s vytvářením patchů oproti -mm, natožpak aby to zkoušeli zkompilovat a otestovat. Podrobnosti později.

-- Andrew Morton

Anton Blanchard má signed-off-by řádek i u telefonních hovorů.

-- AntonBlanchardFacts.com

Co se dostalo do 2.6.25

Od vydání 2.6.24 se do git repozitáře hlavního jádra dostalo nějakých 3800 patchů. To je o něco méně, než by se dalo očekávat, ale Linusova cesta na linux.conf.au to trochu zpomalila. Později se můžeme těšit na obvyklou dávku zajímavých věcí.

Změny viditelné pro uživatele:

• Přibyly nové ovladače pro
  • bezdrátové karty Globe Trotter HSDPA
  • čipy pro akceleraci šifrování HIFN 795x [crypto accelerator chips]
  • tunery Xceive xc2028 a xc5000
  • konvertory analog-digitál Cirrus Logic CS5345
  • několik TV tunerů Beholder TV
  • kamery Syntek DC1125
  • FM radio přijímače Silicon Labs Si470x
  • procesory Atmel AT91CAP9 a Qualcomm MSM7X00A
  • zařízení "systém na čipu" Marvell Orion
  • procesory Marvell Feroceon a SuperH 7203 a 7263
  • systémy SGI IP28
  • ethernetové adaptéry R6040
  • 10Gb síťové adaptéry Broadcom NetXtremeII
  • bezdrátové síťové karty založené na RTL8180 a 8185
  • ethernetové čipy Microchip EN28J60
  • a konečně bezdrátové síťové adaptéry založené na Atheros


• SCSI ovladače Seagate ST-02/Future Domain TMC-8xx a PSI240i byly odstraněny, protože se o ně nikdo nezajímal a nikdo je nespravoval.


• Do šifrovací [crypto] vrstvy byla doplněna podpora proudové šifry [stream cipher] Salsa20 (alespoň pro architekturu x86 - je to implementace v assembleru).


• Do plánovače se dostala nějaká práce na podpoře realtimového provozu; konkrétně bude jádro přistupovat agresivněji k přesouvání úloh mezi procesory, když se bude o stejný procesor přetahovat více realtimových úloh. Implementace cpusetů byla upravena tak, aby spolupracovala s mechanismem domén plánovače. Možnost nastavit velký jaderný zámek [big kernel lock] jako preemptivní je teď zvolena ve výchozím nastavení a časem bude nepreemptivní verze úplně odstraněna. Časovače s vysokým rozlišením mohou být použity pro preempci, takže je férové plánování přesnější. Funkce skupinového plánování byla rozšířena o podporu realtime.


• Byly začleněny patche s preemptivním read-copy-update.


• Podpora pro utilitu LatencyTop.


• Podpora kprobes na architektuře ARM.


• Nový příznak CLONE_IO u clone() způsobí, že budou I/O kontexty (používané v blokovém I/O plánovači CFQ) sdílené s novým procesem-potomkem.


• Nečinná třída [idle class] pro I/O plánování byla změněna, aby nebyla 100% nečinná, když je zařízení v provozu; je tedy mnohem méně pravděpodobné, že by způsobila problémy s obrácenou prioritou [priority inversion], a už není omezena na privilegované procesy.


• Dlouhý seznam nových vlastností ext4, včetně podpory velkých souborů, (velmi) velkých oddílů, kontrolních součtů žurnálu, alokace více bloků a dalších.


• Systémové volání splice() teď podporuje přijímací proudy TCP [TCP receive streams].


• Podpora protokolu Controller area network.


• Dlouho zastaralý usměrňovač síťového provozu [network traffic shaper] byl odstraněn.


• Bylo odvedeno dost práce na kódu síťových jmenných prostorů, který byl začleněn do 2.6.24. Rozšíření povědomí o jmenných prostorech celým síťovacím subsystémem je v tuto chvíli již téměř hotové.

Změny viditelné pro vývojáře jádra:

• Do stromu přibyly čínské překlady několika základních dokumentů o vývoji jádra.


• Hodně změn nízkoúrovňových API modelu zařízení, která pracují s kobjekty a ksety. Tyto změny si vynutily velké množství úprav po celém stromu. Vizte soubor Documentation/kobject.txt, kde najdete popis nového API.


• Nová sada funkcí bezpečnostních modulů pro operace připojování a odpojování souborových systémů.


• API pro zřetězené scatterlisty [chained scatterlist API] bylo doplněno o patche s podporou sg_table.


• Změny v API pro informaci o dokončení blokových požadavků. Vizte níže.

Začleňování teprve začalo, takže příští týden bude připraven další dlouhý seznam. Kromě jiného čeká na začlenění aktualizace stromu x86 čítající 908 sad změn.

Jak zabránit řádění OOM zabijáka pomocí mem_notify

Provozování aplikací, které spotřebují veškerou dostupnout paměť, může být dost nepříjemné. Na linuxových systémech to většinou znamená návštěvu od OOM zabijáka [out-of-memory, OOM killer], který se pokusí najít procesy, jež by šlo odstřelit. Není těžké uhádnout, že stanovování pravidel určujících, který proces bude zabit, není lehké - někdo někde bude vždy nespokojen s tím, jak si OOM zabiják vybere. Patch mem_notify se tomu snaží úplně předejít.

Když začne docházet paměť, je dost možné, že mají aplikace alokovanou i paměť - často jde o keše kvůli lepšímu výkonu - kterou by mohly uvolnit. Koneckonců je většinou lepší se smířit s horším výkonem, než se vyrovnávat s následky toho, že si aplikaci vybere OOM zabiják. Ale v současné době neexistuje způsob, jak by se proces mohl dozvědět o tom, že je jádro s pamětí v úzkých. Popisovaný patch nabízí možnost, aby programy, které to zajímá, mohly sledovat soubor /dev/mem_notify, který by je upozornil, když začne paměť docházet.

/dev/mem_notify je znakové zařízení, které dává najevo nedostatek paměti tím, že začne být možné jej přečíst. Zainteresované programy mohou soubor otevřít a použít poll() nebo select() k monitorování popisovače souboru. Kromě toho může být příznakem FASYNC zapnuto I/O rozhraní ovládané pomocí signálů a systém pak procesu doručí SIGIO signál, když začne být zařízení čitelné. Jakmile k tomu dojde, měl by proces uvolnit všechnu paměť, bez které se může obejít. Pokud bude paměti uvolněno dost, nebude jádro muset přivolávat OOM zabijáka.

Jádro pudla spočívá v tom, jak zjistit, že je málo paměti. mem_notify upravuje shrink_active_list(), aby si všímal přesunu anonymní stránky do neaktivního seznamu, což napovídá, že bude brzy odswapována. Když se to stane, zavolá se pro tu zónu memory_pressure_notify() (s příznakem pressure nastaveným na 1). Zvýší-li se počet volných stránek v dané zóně nad práh určený podle pages_high a lowmem_reserve, je opět zavolána memory_pressure_notify(), ale s příznakem pressure nastaveným na 0, což signalizuje ukončení stavu nedostatku paměti v dané zóně.

Pokud na upozornění o nedostatku paměti čeká více procesů, mohlo by být ke škodě je všechny probudit najednou - problém "splašeného stáda". Aby se tomu předešlo, umožňuje patch vzbudit méně procesů, než kolik jich na událost čeká. Stará se o to nová funkce poll_wait_exclusive(). poll_wait_exclusive() zavolá add_wait_queue_exclusive(), aby mohl být použit člen rodiny wake_up(), což omezí počet probouzených procesů. Dříve byla k dispozici pouze poll_wait(), která používá add_wait_queue(), jež tuto možnost nenabízí. Aby se omezila četnost probouzení procesů, provádí to memory_pressure_notify() jen jednou za pět vteřin.

Výstup /proc/zoneinfo byl upraven, aby obsahoval stav mem_notify. Uživatel to může použít pro diagnostické účely a program pro kontrolu aktuálního stavu nedostatky paměti v zónách.

Komunita vývojářů pro embedded zařízení projevila velký zájem o začlenění této funkce do jádra. Zařízení jako telefony a PDA často běží na hranici svých paměťových možností a když uživatel otevře další aplikaci, před OOM zabijákem v současnosti není obrany. S tímto patchem by programy, které používají hodně paměti, ale vystačily by i s menším množstvím, mohly být upraveny, aby své keše vyprázdnily, když jde do tuhého. A ze změny pamětichtivých programů by těžily i ostatní.

Patch poslal Kosaki Motohiro, ale už předtím prošel několika kolečky v rámci LKML. Původně na něm pracoval Marcelo Tosatti, přičemž Kosaki nedávno představil pátou verzi. Všechny předchozí verze byly přijaty kladně a s poměrně málo komentáři, takže se zdá, že na začlenění nebudeme dlouho čekat.

API pro informaci o dokončení blokového I/O požadavku

Bloková vrstva v řadě 2.6 tradičně poskytovala dvojici funkcí, s jejichž pomocí mohl dát ovladač najevo, že byl I/O požadavek dokončen. Volání end_that_request_first() signalizovalo přenos určitého množství dat a vracelo hodnotu označující, jestli byl požadavek jako celek dokončen. Jakmile byly přeneseny všechny sektory požadavku, bylo na ovladači, aby předal požadavek funkci end_that_request_last(), která provedla koncový úklid. Dále byla k dispozici funkce nazvaná prostě end_request(), která mohla, ale nemusela, celý požadavek ukončit - podle toho, kolik bylo přeneseno dat. Toto API fungovalo dlouhou dobu, ale občas vývojáře ovladačů mátlo. Pro ovladače bylo také obtížné si s tímto rozhraním předávat použitelné chybové zprávy. Takže od 2.6.25 budou mít ovladače jiný způsob, jak oznámit dokončení požadavku.

Po přenesení jednoho nebo více sektorů (nebo v případě selhání) by teď měl blokový ovladač zavolat:

    int blk_end_request(struct request *rq, int error, int nr_bytes);

Kde rq je I/O požadavek, error je nulový nebo záporný chybový kód a nr_bytes je počet úspěšně přenesených bajtů. Pokud blk_end_request() vrátí nulu, byl požadavek plně zpracován a ovladač na něj může zapomenout. Jinak na přenesení stále nějaké sektory čekají a ovladač by měl pokračovat se stejným požadavkem.

blk_end_request() musí pro splnění svého úkolu zabrat zámek fronty. Pokud již ovladač zámek drží, měl by místo toho zavolat __blk_end_request().

Blokové ovladače mezi voláními end_that_request_first() a end_that_request_last() tradičně prováděly několik úklidových úkonů. Patří mezi ně add_disk_randomness(), aby se přispělo do zásoby entropie [entropy pool], vrácení tagů použitých při požadavku a odstranění požadavku z fronty. To vše se provádělo v rámci blk_end_request(), aby se o to ovladače nemusely starat. Některé ovladače však v době mezi dokončením požadavku a odstranění z fronty musejí provést další činnosti. Pro ovladače s tímto druhem speciálních potřeb je připravena samostatná funkce:

    int blk_end_request_callback(struct request *rq, 
                                 int error, 
				 int nr_bytes,
			         int (drv_callback)(struct request *));

V této verzi bude v době mezi dokončením požadavku a koncovým úklidem volána (bez zámku fronty) funkce drv_callback(). Pokud vrátí zpětné volání nenulovou hodnotu, koncový úklid se neprovede. Tato funkce si vždy zabere zámek fronty - neexistuje verze pro ovladače, které už jej drží. Obecně však lze říci, že použití zpětného volání je pravděpodobně znakem přílišné komplikovanosti ovladače.

Změnu doprovází slušná řádka patchů, které na nové rozhraní konvertují všechny ovladače v rámci stromu. Staré funkce byly odstraněny, takže externí ovladače budou muset být opraveny, než začnou s 2.6.25 fungovat.

Diskuse k tomuto článku

[kavol]

hm, mem_notify je určitě dobrý počin, ale obávám se, že se míjí s účinkem u takových běžných OOM situací na normálních strojích s dostatkem paměti - jestliže nějakému procesu začne utíkat paměť (až do "nekonečna"), těžko ji bude uvolňovat, a to, že se mezitím nějaká získá zpět od jiných aplikací, zkáze systému nezabrání, nanejvýš ji oddálí (ale IMHO to udělá věci ještě horšími ... když nějaká aplikace idlí a je prakticky celá odswapovaná, proč ji zase probouzet a vracet její části do paměti, což stojí v danou chvíli drahocenné prostředky, jen proto, aby zjistila, že nemůže už nic uvolnit?)

na druhou stranu, kdyby se to spojilo s OOM killerem, třeba tak, že aplikace, které nebudou na "stop stav" reagovat a budou dále paměť alokovat (kromě nějakého dočasného minima nutného k provedení příprav na uvolnění), sestřelí OOM killer jako první, bylo by to IMHO docela užitečné ... jestlipak se páni vývojáři nad touto jednoduchou heuristikou zamysleli?

[..... Izak .....]

No ja to resim limity, mam swpak pres 3 disky se stejnou prioritou (tedy hodne rychly de fakto v RAID0) a mel jsem problemy s testovanim nekterych pluginu v Gimpu .... ten kdyz sezra veskerou pamet, tak dlouho trvalo, nez jej zabil, pritom do te doby jsem o swapovani nevdel, ale az cazne prerovnavat i swpak, tak je to hudba jek ve windows )

Takze ted, kdyz program sezere vice nejkou mez (rkeneme (RAM+swap) - 300MB ) tak bude ukoncen.

[v.barney]

ale IMHO to udělá věci ještě horšími ... když nějaká aplikace idlí a je prakticky celá odswapovaná, proč ji zase probouzet a vracet její části do paměti, což stojí v danou chvíli drahocenné prostředky, jen proto, aby zjistila, že nemůže už nic uvolnit?

Nemyslím si, že by toto bol problém. Aplikácia, ktorá nemá čo uvolniť sa jednoducho nebude registrovať v mem_notify. Takže by nemala byť volaná takouto udalosťou.

Na druhú stranu, je dobré nejako detekovať procesy, ktoré nekontrolovane alokujú pamäť.

Skôr sa bojím, koľko bude aplikácií, ktoré sa budú takto správať.