Jaderné noviny - 22. 3. 2006

4. 4. 2006 | Robert Krátký

Články - Jaderné noviny - 22. 3. 2006  

Aktuální verze jádra: 2.6.16. Citát týdne. Technický poradní panel OSDL. Co bude nového v 2.6.17. Na poslední chvíli se diskutovalo o unshare(). Řešení problému s hladověním ve scheduleru.

Aktuální verze jádra: 2.6.16

Aktuální verze jádra je 2.6.16. Vydána 19. března. Od 2.6.16-rc6 bylo začleněno poměrně dost oprav, ale nic zásadního. Pro ty z vás, kdo dění moc nesledují: mezi velké, pro uživatele patrné změny patří clusterový souborový systém OCFS2, několik síťovacích změn, včetně kontroly zahlcení CUBIC, podpory TIPC a IPv6 verze DCCP, migrace swapu a patche pro přímou migraci, nové třídy scheduleru [plánovače] SCHED_BATCH, pár nových systémových volání pro souborové systémy a kódu pro detekci a opravu chyb. Velké interní změny zahrnují změnu na mutex a kód časovače s vysokým rozlišením. Podrobnosti najdete v dlouhém changelogu.

Git repozitář hlavního stromu obsahuje velkou hromadu patchů začleněných do 2.6.17-rc1; vizte shrnutí níže.

Aktuální -mm strom je 2.6.16-rc6-mm2. V poslední době byl v -mm reorganizován kód migrace stránek (mezitím už byl začleněn), bylo provedeno pár změn v časovavačích s vysokým rozlišením, vylepšen scheduler a přidány patche předělávající MD RAID.

Citát týdne

Já jen vynucuji pěkné chování pod hrozbou pevného lana. Jeden konec připevním k balvanu, druhý na krk úlohy. Úloha se sama rozhodne, jestli bude oběšena, a uživatel rozhoduje o délce lana.

-- Mike Galbraith. Kdo říká, že je těžké porozumět patchům pro scheduler?

Technický poradní panel OSDL

Jak už bylo slibováno dříve, OSDL oznámila vytvoření "technického poradního panelu", který má pomáhat se zlepšováním vztahů s vývojářskou komunitou kolem linuxového jádra. Prvními členy jsou James Bottomley, Wim Coekaerts, Randy Dunlap, Greg Kroah-Hartman, Christoph Lameter, Matt Mackall, Theodore Ts'o, Arjan van de Ven a Chris Wright.

Co bude nového v 2.6.17

Proces začleňování patchů do hlavního stromu pro 2.6.17 již probíhá několik dní. Bylo zařazeno kolem 1500 patchů, i když počet viditelných změn je relativně nízký. Zatím se do jádra dostalo toto:

• Velká aktualizace SPARC, která, mimo jiné, obsahuje podporu pro novou architekturu "Niagara".
• Značný počet aktualizací bezdrátového síťování, včetně nového vývoje v oblasti 802.11. Ovladač ipw2200 prošel změnami, které - kromě jiného - vyžadují, aby měli uživatelé karty verzi firmwaru minimálně 3.0.
• Kód DCCP pokračuje ve vývoji; kromě dalších věcí byla přidána i CCID2 (využívající kontrolu zahlcení podobnou jako TCP).
• Netfilter má helper pro sledování spojení protokolu H.323.
• Velká aktualizace JFS.
• Obrovský balík video/DVB patchů, který přidává podporu pro množství nových zařízení a opravuje mnohé problémy.
• Velká aktualizace sériového ATA. Subsystémy SCSI a ALSA byly také rozsáhle aktualizovány.
• Několik USB audio ovladačů bylo odstraněno; USB audio hardware je lépe podporován subsystémem ALSA.
• Na mnoha místech stromu pokračuje změna semaforů na mutex.
• Začleněno EXPORT_SYMBOL_GPL_FUTURE().
• Byla odstraněna volba SLAB_NO_REAP, která neustále způsobovala, že nebyl pročištěn slab, když měl systém nedostatek paměti. Typedef kmem_cache_t začíná být nahrazován pomocí struct kmem_cache.
• Rezervace "obrovských" stránek byla zpřísněna, aby se při některých druzích použití zabránilo nedostatku paměti [out-of-memory]. Na velké stránky lze teď také použít mprotect().

Na poslední chvíli se diskutovalo o unshare()

Jedním z mnoha nových systémových volání přidaných do jádra 2.6.16 je unshare(). Jeho účelem je dělat opak toho, co dělají různé sdílecí [sharing] parametry [flags] clone(): používá se k odpojení některých zdrojů procesu od zdrojů jeho předků a sourozenců. S unshare() může proces požádat o své vlastní souborové systémy, jmenné prostory nebo tabulku popisovače souboru. "Odsdílení" [unsharing] dalších zdrojů, včetně undo informací semaforů, virtuální paměti, obsluhovačů signálů atd. je plánováno pro budoucí verze.

Těsně před finálním vydáním 2.6.16 se objevilo pár otázek ohledně unshare(); jen některé z těchto otázek byly ve výsledném jádře dořešeny.

Jedna z nich se týkala implementace unshare(CLONE_VM), která způsobuje, že volající proces přestane sdílet paměť s ostatními. Zdálo se, že tato funkčnost je hotová a kompletní, ale Oleg Nesterov si všiml, že kód nebere v potaz možnost, že by hlavní část adresného prostoru mohla být v procesu. Řešením je prozatím zakázání odsdílení paměti. Vypadá to, že není nikdo, kdo by tuto funkci rychle potřeboval, a už bylo příliš pozdě na pokusy o opravu funkce spravující hlavní paměť.

Eric Biederman vznesl několik otázek týkajících se API unshare(), které by byl rád opravil dříve, než se stane součástí vydaného jádra. Jedním z problémů bylo použití stejné sady parametrů jako používá clone() pro specifikaci sdílení. Eric tvrdí:

sys_unshare neumí implementovat ani polovinu parametrů clone a ty, které implementuje, mají lehce jinou sémantiku než u clone. Použitím odlišné sady parametrů bychom naznačili, že jde o rozdílné věci.

Diskuze se příliš daleko nedostala, protože Linus dává přednost stejným parametrům a nevypadá to, že by to někoho jiného nějak extra trápilo.

Erikova další připomínka byla o tom, že unshare() nezjišťuje, zda parametry existují; prostě je tiše ignoruje. Takže si uživatelský prostor může požádat o odsdílení zdrojů, které unshare() nezná nebo nepodporuje, a nebude vrácena žádná chyba. To by mohlo v budoucnu, kdy se očekává rozšiřování sady platných parametrů pro unshare(), představovat problém. Program napsaný tak, aby využíval nové parametry, by se nemusel chovat dle očekávání, pokud by byl spuštěn na jádře 2.6.16; funkčnost, kterou bude požadovat, nebude k dispozici, ale jádro o tom nepodá zprávu.

Eric poslal patch, který řešil obě záležitosti: názvy parametrů a zjišťování platných parametrů. Nebyl však do 2.6.16 začleněn. Samotný test na známé parametry začleněn být mohl (a skutečně byl začleněn do 2.6.17), ale kombinovaný patch přijat nebyl. Andrew Morton poznamenal: "Tvůj patch dělal dvě rozdílné věci - z toho plyne poučení." Zvláště těsně před vydáním finálního jádra je důležité připravovat patche úzce zaměřené na jediný problém.

Řešení problému s hladověním ve scheduleru

Linuxový CPU scheduler [plánovač] urazil dlouhou cestu od dob čerstvého 2.6, kdy byl příčinou nemalých starostí. Plánovací domény napravily spoustu potíží na větších systémech, zatímco celá sada heuristiky pro interaktivitu pomohla lépe fungovat desktopům. Zvláště práce s interaktivitou je založena na pojmu "průměr spánku" [sleep average]. Každý proces, který stráví hodně času spaním v poměru k času, kdy běží, je považován za "interaktivní" a je mu přidělena vyšší priorita.

Tento mechanismus funguje tak dobře, že na reakční časy současných 2.6 jader si stěžuje málokdo. Občas se však stane, že někdo přijde se zátěží, které se podaří scheduler zmást, a celý desktop zatuhne. Mike Galbraith se některými z těchto případů zabývá a připravuje patche, které by měly pomoci se zmírňováním podobných problémů.

Linuxový scheduler udržuje dvě "pole" front pro každý procesor. Každému procesu je při startu přidělen časový úsek a je zařazen do "aktivního" pole, kde může bojovat o CPU. Jakmile časový úsek vyprší, proces se přesune do "prošlého" pole, kde vyčkává, dokud všechny ostatní procesy nepoužijí své úseky. Když se všechny procesy ocitnou v prošlém poli, pole jsou prohozena a celý postup se opakuje.

V jádře 2.6 je však výjimka: proces považovaný za interaktivní (protože stráví dostatek času v přerušitelných spáncích) bude po vypršení svého časového úseku vrácen do aktivního pole. Díky tomu by neměl interaktivní proces být donucen čekat, až se nějaký dlouhotrvající dávkový proces prokouše svým časem. Aby tento mechanismus nemohl zcela zablokovat prošlé procesy, scheduler kontroluje, jestli procesy v prošlém poli nečekají příliš dlouho. Po překročení prahu "vyhladovění" jdou všechny procesy po vypršení svých časových úseků do prošlého pole, což scheduleru umožní provést prohození polí v relativně blízké budoucnosti.

Mike zjistil, že na systému, kde běží silně zatížený Apache server, mohou některé úlohy hladovět velmi dlouhou dobu; vypadá to, že mechanismus, který má bránit vyhladovění, nefunguje správně. Problém vězel v probouzecím kódu. Kód vždy dával čerstvě probuzené procesy do aktivního pole bez ohledu na to, co se dělo ve zbytku systému. Protože bylo neustále probouzeno velké množství serverových procesů díky příchozím požadavkům, scheduler se vůbec nedostal k prohození polí. Řešením bylo vložit kontrolu hladovění do __activate_task(); výsledkem je, že pokud prošlé procesy hladoví, budou procesy probouzeny do prošlého pole. Tato malá oprava se postarala o velkou část problému.

Větší opravy však byla potřeba pro patch přiškrcující úlohy, na kterém Mike už nějaký čas pracuje. Součástí této práce je několik oprav, ale základní zjištění je následující: kód, který se stará o "průměr spánku" může být příliš štědrý k procesům, které spí jen chvilku. Proces, kterému se podaří pravidelně na krátkou chvilku usnout, může výrazně zvýšit svoji prioritu. Natolik, že vytlačí ostatní procesy běžící na daném systému. A získá-li proces bonus interaktivity, může si ho nějakou dobu podržet. To vše je záměrné; některé interaktivní programy mohou velmi dlouho sedět a pak chvilku provádět náročné výpočty. Vezměte si třeba X server s tím pěkným kompozitním správcem oken; spoustu času je nečinný, jen aby procesor sešlápl, když začne uživatel tahat okna po obrazovce. Ale takové chování může také udělit prioritní bonus interaktivity procesům, které ve skutečnosti interaktivní nejsou.

Řešení zahrnuje několik změn. Jednou z nich je prostě menší štědrost při rozdělování bonusů. Ale jádrem patche je funkce nazývaná refresh_timeslice(). Tato funkce porovnává aktuální průměr spánku s časem, který proces doopravdy stráví v procesoru. Na základě tohoto srovnání je upraven škrtící čas pro každý proces. Je-li CPU používáno více než by odpovídalo průměru spánku, je čas přiškrcení posunut dozadu; jinak dopředu. Narazí-li proces na čas přiškrcení, začne jeho průměr spánku rychle mizet, což ho zbaví jeho bonusu interaktivity.

Čas přiškrcení poskytuje chvilky oddechu [grace periods], které procesům dovolí krátké využití CPU, aniž by byly penalizovány. Množství času na oddech může být upraveno pomocí dvou nastavovátek exportovaných kódem přiškrcení. "Oddech 1" je množství času, které nové procesy dostanou, aby mohly být nastaveny jejich hodnoty průměrů předtím než budou předhozeny škrtícímu mechanismu. "Oddech 2" je doba, po kterou mohou procesy přesáhnout předpokládaný procesorový čas, než začne fungovat přiškrcování. Ohledně přidání těchto nastavovátek se objevilo několik stížností; vypadají jako další obskurní způsob ladění jádra, který stejně většina administrátorů nebude umět správně využít. Takže se tlačilo na to, aby byla nastavovátka nahrazena obyčejným přepínačem zapnuto/vypnuto. Systémy určené pro interaktivní využití ponechají přiškrcování zapnuté, serverové systémy ho prostě celé vypnou. Vyřešení této záležitosti možná zpozdí přijetí patche, i když proti jeho zbytku nikdo nic nenamítá.

Diskuse k tomuto článku

[camlost]

Technický poradní panel? are you flying? :-O

OSDL's Technical Advisory Board rozhodně není panel. výbor nebo ... kolegium. radši to zkopírujte v originálu, je to lepší než to takhle prznit. :-/

[Xerces]

Board by mohla být spíše nástěnka, deska. To by taky bylo fajn Technická Poradní Deska Mě se ty zprzněné překlady moc líběj (pokud je uveden v závorce originál).

[Robert Krátký]

Neznáš termín "poradní panel"? A co třeba "panelová diskuze"? Panel nemusí být jen kus betonu, ze kterého se staví sídliště. Také to může být skupina lidí.

[Jiří (BoodOk) Kadeřávek]

Panel tedy v cestine zadna skupina lidi rozhodne neni. Ze si to managori takhle pojmenovali nic neznamena. Je to asi stejne ceske jako katovat naklady. V cestine mame vybor, komisi, kolegium, pracovni skupinu, ale zadne lidske panely.

[Jiří (BoodOk) Kadeřávek]

Ale jinak diky za jaderne noviny

[Robert Krátký]

Manažeři s tím nemají nic společného. Zkus nahlédnout do slovníku cizích slov. Nemám teď žádný po ruce, ale řekl bych, že tam najdeš něco ve spojení se sociologií. Panel jako skupina lidí, na které se provádí výzkum nebo něco v tom smyslu. A pak Googlu zadej "poradní panel" a uvidíš, že použití v tomto smyslu není nijak ojedinělé.

[Jan Přech]

No dobře, dobře, ale prece jenom to slovo vypadá trochu divně, ne? Možná ta kritika neměla být tak kategorická. Myslím, že prostě vyjadřovala autorovu nechuť k často se vyskytujícím polopřeloženým zpotvořeninám, mezi kterými je "panelová diskuse" ještě slabý odvar. (co třeba taková "vykomunikovaná environmentální strategie" a podobné jazykové zrůdy...) Tuto nechuť úplně chápu, i když svůj boj proti imho (!) stupidnímu výrazu "funkcionalita" už jsem dávno vzdal.

[Robert Krátký]

Já chápu ty stesky nad "manažerskou češtinou", ale nejsem si vědom, že bych ji používal. A jsem přesvědčen, že ani tohle není ten případ. Slovo "panel" se v tomto smyslu používá už dost dlouho, není to výmysl poslední doby.

[Jan Přech]

Já bych to nezužoval na manažerskou češtinu, treba zrovna ta "funkcionalita" neni zrovna manažerský výraz. Měl jsem na mysli obecný rys "paranormálních jazykových jevů", ať už importovaných polopřeloženin, přidání nového jazykově těžko pochopitelného významu už existujícímu slovu, nebo vytváření zcela nových unikátních patvarů... Ježiši, mluví ze mě chlast

Takže jsem v podstatě chtěl říct (teď už stručně bez pseudointelektuálních kydů ): "Pokud použiju 'poradní panel' místo 'poradní skupina', nemůžu se divit, že si leckdo představí tunu betonu a pak nad tím nahlas kroutí hlavou. To, že slovo 'panel' v jistých obskurních koutech češtiny opravdu může znamenat 'skupina' na tom nic nemění." To slovo je v tomhle významu imho prostě divné.

P.S.: Díky za Jaderné noviny, moc se mi po nich stýskalo. Pokud kritice zbývají už jenom hovadiny typu poradní panel, je to myslím dobrý indikátor kvality

[Robert Krátký]

zrovna ta "funkcionalita" neni zrovna manažerský výraz

Ale to také nepoužívám

mluví ze mě chlast

V tuhle hodinu? Závidím...

Pokud kritice zbývají už jenom hovadiny typu poradní panel, je to myslím dobrý indikátor kvality

To mě těší. Víc se bojím technických termínů.

[Jan Přech]

Jsem (i když to tak podle komentářů možná nevypadá) zcela střízliv, takže není třeba závidět, je pouze třeba doplnit si vzdělání

[asd]

az to budu nekdy hledat na googlu, tak stejne potrebuji znat Technival Advisory Board, tak proc to prekladat, kdyz navic nativni jazyk toho boardu bude zcela jiste anglictina!!!

[Filip Jirsák]

Díky za Jaderné noviny. Mám pocit, že se podařilo odstranit drobné mušky vytýkané předchozímu dílu, tentokrát prostě nemám ani malé bezvýznamné výhrady

[al-Quaknaa]

Připojuji se k poděkováním + hlavní vylepšení, které se mi líbilo, byl stručný a přehledný souhrn plánovaných změn v 2.6.17. Super!
A citát týdne taky rulezz ;)

[Robert Krátký]

hlavní vylepšení, které se mi líbilo, byl stručný a přehledný souhrn plánovaných změn v 2.6.17.

No, ona je to spíš náhoda, protože i tentokrát jsem čerpal pouze z LWN.net. Další zdroj kratších zpráv stále sháním.

[asd]

koukam anglicky kerneltraffic.org uz byl docasne/trvale pozastaven. skoda toho. obcas jsem byl rad, kdyz jsem prolitl nadpsiy a byl v obraze a kdyz me neco zaujalo pripadne pokud to vyplivnul google...

jiny zdroj by mohl byt treba i kerneltrap.org ?

[Robert Krátký]

koukam anglicky kerneltraffic.org uz byl docasne/trvale pozastaven.

Už je to dost dlouho. Ostatně jsem o tom mluvil v blogu - bylo potřeba najít náhradu.

jiny zdroj by mohl byt treba i kerneltrap.org ?

Už jsem Jeremymu psal, protože to kdosi navrhl v diskuzi pod minulým dílem. Čekám, co na to řekne.

[Jan Zahornadsky]

Moc hezké, přijde mi to dokonce lepší než Kernel Traffic, kde se zbytečně někdy rozebíraly flamewary vývojářů.

[DjAARA]

Me se flamewary vyvojaru libily - clovek si udelal predstavu o tom jak to v komunite vyvojaru kernelu vypada . Tedy ze ne vsichni maji stejny nazor a ze stejne spolecne pracuji na vylepsovani.

[xxxxxxxx]

diky za tuhle praci

[peter]

Hmm, zaujimave s tym schedulerom. Napr. ked pozeram webstranku a je tam nejaky flash, tak na pomalsom stroji moc ten proces nespi, nie? Potom to zacne trhat, teda aspon mne. Moze to byt schedulerom? Alebo zlym chladenim CPU? (ten pocitac je fakt pomaly, flash je prenho dost fuska)