Jaderné noviny - 18. 6. 2008

6. 8. 2008 | Jirka Bourek | Jaderné noviny | 3182×

Aktuální verze jádra: 2.6.26-rc6. Proč nejsou některé ovladače začleňovány brzo. Peter Ziljstra: Od DOSu k hackování jádra. Stav patchů pro škálovatelnost odstraňování stránek.

Obsah

• Aktuální verze jádra: 2.6.26-rc6
• Proč nejsou některé ovladače začleňovány brzo
• Peter Ziljstra: Od DOSu k hackování jádra
• Stav patchů pro škálovatelnost odstraňování stránek

Aktuální verze jádra: 2.6.26-rc6

Současné vývojové jádro 2.6 je 2.6.26-rc6, které Linus vydal 12. června. Rád bych řekl, že diffy se zmenšují a věci zklidňují, ale lhal bych. Další týden, další -rc a dalších 350 commitů. Všechny detaily najdete v dlouhém changelogu.

V době psaní tohoto článku se od vydání 2.6.26-rc6 do gitového repozitáře hlavní řady dostalo okolo 140 commitů. Zahrnují mnoho oprav a nový ovladač pro hodiny reálného času FM3130.

Současná verze -mm stromu je 2.6.26-rc5-mm3. Andrew říká: Cílem je odstranit z cesty všechny ty pitomé chyby, aby se dalo MM pořádně otestovat. Mezi jinými toto vydání obsahuje nejnovější verzi patchů škálovatelnosti odstraňování stránek [pageout] (vizte níže).

Současné stabilní jádro 2.6 je 2.6.25.7 vydané 16. června. Obsahuje důležité opravy, jejichž seznam je poněkud dlouhý.

Proč nejsou některé ovladače začleňovány brzo

Hlášení o jaderných oopsech od Arjana van de Vena je vždy zajímavé čtení; je to rychlé shrnutí toho, co v uplynulém týdnu nejčastěji způsobovalo pády jádra. Ukazuje se tak na místa, kde jsou k nalezení ty nejurgentnější chyby. Někdy toto hlášení nicméně vyvolá další diskuzi - vezměme hlášení z 16. června, které poznamenává, že docela dost jader spadlo kvůli ne zcela hotové aktualizaci, kterou přidává Fedora. Ingo Molnár se na toto hlášení zaměřil se stížností na vývojový proces:

Mám podezření, že Fedora to udělala, aby zprovoznili více hardwaru a/nebo opravili chyby bezdrátových zařízení v hlavní řadě. Přál bych si, abychom místo toho začleňovali nové ovladače do hlavní řady, abychom měli jedno testovací místo a jedno místo, kde se soustředí snahy.

To samé pro Nouveau: Stará se o něj Fedora a já nechápu, proč tak velký kus práce není dělán v hlavní řadě a ne jen s pomocí od hlavní řady.

Potom v diskuzi pokračoval s tímto pozorováním:

O tom hlavně mluvím: když něco zkazíme a nezačleníme kód OSS ovladače, který byl venku včas - a s tím bezdrátovým jsme to zkazili pořádně - měli bychom uznat chybu a spolknout tu hořkou pilulku.

Tento komentář vyvolal nešťastné odpovědi od síťových vývojářů, kteří mají pocit, že se na ně kritika zaměřila neoprávněně. Říkají, že bezdrátové ovladače byly začleněny při první skutečné příležitosti a snažit se je začlenit dřív by věci jenom zhoršilo. Autor článku uznává, že k chybám ohledně bezdrátových ovladačů došlo, ale tyto chyby nemají se začleněním do hlavní řady moc společného. Byly v něčem jiném:

• Raní vývojáři bezdrátových zařízení se ve skutečnosti nesnažili vyřešit problém související s bezdrátovým síťováním; jenom chtěli, aby jejich karty fungovaly. Správce bezdrátových zařízení John Linville kdysi Jonathanu Corbetovi řekl, že tyto karty byly po léta obsluhovány tak, jako by to byly ethernetové adaptéry, což rozhodně nejsou. Když se tito vývojáři dostali k řešení problémů specifických pro bezdrátové síťování, vytvořili své vlastní bezdrátové stacky, které byly obsaženy přímo v ovladačích. Nebyl vytvořen žádný obecný bezdrátový framework.

  Až v roce 2004 Jeff Garzik zahájil projekt, který se snažil o vytvoření obecného bezdrátového stacku pro Linux - začal se stackem (HostAP), který později nebyl uznán za nejlepší volbu. Práce na HostAP - která předně začala pozdě - byla nakonec opuštěna.

• Síťový stack nakonec vyvinut byl - mac80211 - svůj život začal jako proprietární kód vytvořený zcela bez revizí a dohledu komunity. Jak se dalo čekat, obsahoval mnoho problémů, jejichž vyřešení vyžadovalo víc než rok práce. Dokud nebyl mac80211 v rozumném stavu, nebyl způsob, jak ovladače začlenit.

Výsledkem toho všeho (a také občasných soudních tahanic) je, že bezdrátové síťování v Linuxu bylo po léta opožděné a teprve teď se blíží nějakému stabilnímu stavu. Proto není překvapení, že kód se v této oblasti čeřil a že se věci občas rozbijí. Je ale těžké říct, jak by časnější začlenění bezdrátových ovladačů významněji v této situaci pomohlo.

Nezačlenění ovladače Nouveau - reverzním inženýrstvím vyvinutého ovladače pro NVIDIA karty - lze také jednoduše vysvětlit: vývojáři ještě o začlenění nepožádali. Mínění o Nouveau je takové, že ještě není v bodě, kde by se dalo označit za funkční. Také jsou zde záležitosti ohledně API pro uživatelský prostor, které je potřeba vyřešit. Rozbití kódu v uživatelském prostoru je vždy přijímáno s nevolí, takže začlenění kódu, pokud jsou jeho rozhraní pro uživatelský prostor ještě nestálá, je téměř nemožné.

James Bottomley přidal další důvod, proč může ovladač zůstat mimo hlavní řadu, i když by ho autor rád začlenil:

Můj pohled na věc je takový, že když se objeví nový ovladač, máme omezené množství času na to, abychom autora přiměli udělat nezbytné změny, takže ho zkouším revidovat a vyjasnit většinu největších záležitostí tak brzy, jak je to možné. Nicméně kvůli tomu, že jediná páka, kterou mám, je začlenění, mám tendence držet ten ovladač mimo strom, dokud nejsou problémy vyřešeny.

Jinými slovy, kontrola nad tím, které ovladače budou mít přístup do stromu hlavní řady, je jediný klacek, který správci subsystémů mají, když mají pocit, že je potřeba donutit vývojáře, aby v ovladači udělal změny. Jednoduché začlenění ovladačů bez ohledu na technické námitky (o což se mnoho vývojářů snaží) by mohlo omezit snahu těchto vývojářů o to, aby se jejich kód dostal do perfektního stavu - a není vždy jisté, že ostatní zakročí a tu práci odvedou.

Na druhou stranu myšlenka, že kód ve stromě bývá méně zachybovaný než kód mimo strom, je relativně nekontroverzní. Proto minimálně pro mnoho ovladačů politika "nejdřív začlenit, později opravit" může vést k nejlepším výsledkům za nejkratší čas. Jedna věc je jistá - tato diskuze se jen tak neztratí; je šance, že letošní kernel summit (naplánovaný na září) se touto záležitostí bude zabývat.

Peter Ziljstra: Od DOSu k hackování jádra

Ve diskuzi na linux-kernel, která se zabývala opravením Projektu jaderných údržbářů [Kernel Janitors project], vystoupil Peter Zijlstra s návrhem, jak přilákat lepší přispěvatele k jádru. Protože on sám je relativně nový přírůstek jaderné komunity, jeho cesta od uživatele Linuxu k jadernému hackerovi může sloužit jako vzor pro ostatní, kteří začínají. Požádali jsme e-mailem Petera o doplnění několika detailů.

LWN: Jak jsi začal s Linuxem? Co tě přitáhlo?

Peter: Někdy v době, kdy přišly Win95, pokud si dobře vzpomínám. Programoval jsem v DOSu dema [demo coding], což znamenalo rebootovat stroj pokaždé, když jste něco zkazili. A zatímco rebootování DOSu bylo rychlé, dělat to samé na Win95 bylo všechno jen ne rychlé.

Jeden známý mi v té době ukázal Unix/Linux a já se začal učit programování ve skutečném prostředí. Všechno programování do té doby bylo v podstatě ve volném prostředí, kde bylo nutné šťourat se v hardwaru, aby se dalo cokoliv udělat.

Takže zpočátku to bylo kouzlo opravdového víceúlohového operačního systému (s ochranou paměti), co mě přimělo ho používat - nemuset pořád rebootovat stroj a luxus používání debuggeru.

LWN: Jak rychle jsi začal s rýpáním v jádře? Na co ses díval prvně a proč?

Peter: Jádro... no, to trvalo vážně dlouhou dobu. Představení Linuxu bylo v roce 95/96. Moje první skutečné jaderné patche přišly o deset let později.

V těchto deseti letech jsem se o programování naučil hodně. Dozvěděl jsem se o programování pro unixové systémy, o C++, vícevláknovém programování, databázových enginech a celé škále dalších zajímavých věcí.

Někdy v té době jsem se dostal ke skutečnému připojení k Internetu a začal jsem sledovat mailové konference, včetně LKML - musel jsem je sledovat okolo pěti let, než jsem si skutečně sedl a napsal nějaké patche.

Během té doby jsem možná poslal několik triviálních oprav při překladu a vzpomínám si na to, že jsem našel únik priority v jednom z realtime patchů. Ale jádro jsem aktivně nevyvíjel - jenom se mi líbilo provozovat opravdu exotické záležitosti, znáte to, Gentoo a překládání téměř všeho z CVS.

Takže co mě přimělo začít s jádrem... nemůžu si docela vzpomenout, jak k tomu došlo, ale narazil jsem na nějaké věci z pokročilého nahrazování stránek [Advanced Page Replacement] od Rika (van Riela). V této oblasti jsem se pohyboval dříve, když jsem pracoval na databázových enginech, a nedávno jsem na to narazil také v práci. Takže jsem začal číst nějaké materiály a některé z navrhovaných jaderných patchů a začal jsem se tím zabývat.

Vykašlal jsem se v podstatě na všechno, co jsem dělal ve svém volném čase (programování WindowMakeru, psaní serializační třídy C++ ASN.1-DER, psaní nového LDAP serveru a jsem si jistý, že mi někde na disku hnijí i další projekty :-)), a začal jsem dělat na jádře.

Proč... to si nejsem jistý - určitě mě to dostalo tam, kde jsem začal - ke shazování strojů (a časy bootu se během posledních deseti let vůbec nezlepšily).

Myslím si, že to byla ta výzva - věděl jsem, že bych mohl napsat cokoliv z toho, na čem jsem dělal, tyhle záležitosti ohledně nahrazování stránek byly úplně novou výzvou a abych byl upřímný, jaderný kód v té době nevypadal tak těžce (pche, jaký jsem byl ignorant...).

LWN: Jak dobře byly tvé příspěvky přijímány jadernými vývojáři? Udělal jsi na cestě nějaké špatné kroky?

Peter: Některé byly přijímány lépe než jiné. Myslím si, že pro každého jaderného vývojáře je přirozené, že si vytvoří vlastní hromádku nepřijatých patchů. Ne všechny se dostanou dál. Tím jsem se ale nenechal odradit, člověk se z jejich psaní něco naučil.

Špatné kroky, he, ty dělám stále . I když se zdá, že mnoho lidí si to nemyslí, jaderní vývojáři jsou také lidé.

LWN: Jaké návrhy máš pro lidi, kteří se dneska chtějí zapojit do vývoje jádra?

Peter: Prostě to udělejte - opravdu je to tak jednoduché. Jo a neobávejte se kritiky, stejně ji obdržíte - po lopatách. Kritika není osobní, je to jenom o vašem patchi. Jsou dvě věci, které můžete udělat:

• přijmout ji a podle toho jednat
• přesvědčit toho druhého, že nemá pravdu

OK, nakonec může být osobní, ale to jenom v případě, že opakovaně nesplníte oba z bodů výše.

LWN: Nedávno se hodně mluvilo o Projektu jaderných údržbářů, myslíš si, že je tento projekt dobrá cesta, jak se zapojit do vývoje jádra? Co si myslíš, že by se mělo v tomto (nebo jiném) projektu udělat jinak, aby se přilákalo více a lepších přispěvatelů?

Peter: Nejsem si jist. Ta věc okolo Jaderných údržbářů skutečně nevypadá, že by fungovala. Myslím si, že to může být kvůli dvěma věcem:

1. Nemáme na dostatek jednoduchých, ale zajímavých věcí (neříkám, že nejsou žádné, ale není žádný seznam). Myslím si, že projekt obsahující skutečnou výzvu by byl lepší, než tupé pročišťování kódu.
2. Jádro skutečně není místo pro nováčky; a to bych měl teď vysvětlit, než to bude špatně interpretováno :-).
   • Věci jsou opravdu mnohem jednodušší, pokud jste trochu kompetentní v (unixovém) systémovém programování předtím, než začnete s jádrem
   • Programování jádra je samotářská práce, ve které vy musíte udělat věci, protože nikdo jiný je neudělá za vás. To neznamená, že vám nikdo nebude moci poradit, když budete mít dotaz. Také vás ale nikdo nebude k ničemu nutit - musíte sami chtít.

Nic z toho neznamená, že nemůžete začít pracovat na jádře bez znalosti C nebo programování vůbec, ale raději se připravte na pekelnou jízdu (ano, jsou lidé, kteří se naučili C prací na jádře, ale to bude vyžadovat skutečně velmi silnou vůli).

Asi se snažím říct, že skutečně musíte chtít jádro programovat. Není jiný způsob, jak se stát jaderným vývojářem, než to jednoduše dělat.

LWN: Práce na Linuxu je tvoje zaměstnání, hobby nebo obojí?

Peter: Obojí; zpočátku to bylo ve volném čase vedle $ZAMĚSTNÁNÍ. Ale poté, co jsem to takhle dělal přes rok, mě moje žena postrčila k tomu, abych si našel nějaké zaměstnání ve vývoji jádra, protože práci na jádře jsem si zjevně užíval víc než $ZAMĚSTNÁNÍ a ona chtěla část mého volného času pro sebe ;-).

Takže jsem se přihlásil na pozice jaderného vývojáře u několika z větších prodejců a Red Hat vyhrál závod.

To, že jsem měl za sebou rok práce s jaderným kódem a LKML, určitě pomohlo v tom, že jsem získal tuto skvělou příležitost. Zmínil jsem už, že absolutně miluji práci na jádře?

Takže nyní se v jádře hrabu celý den a každý den...

LWN: Na jakých jaderných projektech v současnosti pracuješ? Na jakých věcech očekáváš, že budeš pracovat v budoucnu?

Peter: Současné aktivní projekty jsou skupinové plánování a nějaká práce na -rt. Měl bych se zase zaměřit na kód swapování po síti, protože jsou v něm nějaké nedotažené záležitosti.

Budoucnost... no, uvidíme, co se stane, na práci je spousta zajímavých věcí.

Rádi bychom Peterovi poděkovali, že si našel čas na zodpovězení našich otázek.

Stav patchů pro škálovatelnost odstraňování stránek

Sada patchů vylepšující škálovatelnost virtuální paměti, na kterou dohlíží Rik van Riel, je ve vývoji přes rok; LWN se na ni naposledy dívaly v listopadu 2007. Od té doby bylo do této sady přidáno mnoho nových vlastností a jako celek se sada přiblížila k bodu, kde může být zvažováno začlenění do hlavní řady. Je tedy na místě věnovat jí další pohled.

Jedna z hlavních změn, kterou zavádí tento patch, je stále stejná: odděluje seznamy nedávno nejméně používaných [least-recently-used, LRU] stránek na stránky zálohované soubory a stránky zálohované swapem. Když je v paměti těsno, obecně je preferováno odstranit stránky z cache stránek (ty stránky, které jsou zálohovány soubory) místo anonymní paměti. U stránek, které jsou zálohovány soubory, je méně pravděpodobné, že bude potřeba je zpětně zapsat na disk, a více pravděpodobné, že na disku již budou, což urychlí jejich načtení zpět, pokud to bude potřeba. Současná linuxová jádra nicméně udržují oba typy stránek v jednom LRU seznamu, což nutí kód odstraňování stránek k prohledávání (potenciálně velkého množství) stránek, které nemá zájem odstranit. Rikův patch zlepšuje situaci rozdělením LRU seznamu na dva, což umožní odstraňovacímu kódu dívat se pouze na stránky, které skutečně mohou být kandidáty na odstranění.

Nastane nicméně i situace, kdy je potřeba znovuzískat i anonymní stránky. Jádro se pak bude snažit vybrat nejvhodnější stránky k odstranění tak, že najde ty, na které nebylo nedávno odkazováno. Udělat to ale vyžaduje projít celý seznam anonymních stránek a nulovat u každé bit "referenced" - "odkazováno". Velký systém může mít mnoho milionů stránek; iterace přes celou sadu může zabrat hodně času. A jak se ukazuje, není to zcela nutné.

Sada patchů škálovatelnosti VM mění toto chování jednoduše tak, že uchovává určité procento anonymních stránek systému v seznamu neaktivních - na prvním místě, kam se systém dívá, když hledá stránky, které je možné odstranit. Tyto stránky se postupně přesouvají na začátek seznamu, ale když je na ně odkázáno, přesunou se zpět do seznamu aktivních. Zjednodušeně tento patch používá určitou formu testu na "referenced" na část anonymní paměti - bez ohledu na to, jestli jsou právě odstraňovány anonymní stránky - místo toho, aby se snažil určit stav odkazování všech anonymních stránek, až když se jádro rozhodne, že některé z nich potřebuje zpět.

Další sada patchů se zabývá jinou situací: stránkami, které nelze odstranit vůbec. Tyto stránky mohly být například v paměti uzamčeny systémovým voláním, jako je mlock(), mohou být částí zamčené SYSV sdílené oblasti paměti nebo být částí RAM disku. Mohou to být jak v stránky v cache, tak anonymní stránky. Tak jako tak nemá smysl, aby kód, který zajišťuje znovuzískávání, tyto stránky zkoumal, protože je nebude moci odstranit. Současný kód ovšem tyto stránky zkoumat musí.

Toto nepotřebné prohledávání, jak se ukazuje, může představovat problém. Rozsáhlý dokument o neodstranitelných LRU zahrnutý v patchi říká:

Například nenuma platforma x86_64 s 128 GB hlavní paměti bude mít přes 32 milionů 4k stránek v jedné zóně. Když bude velká část těchto stránek neodstranitelná z jakéhokoliv důvodu (vizte níže), vmscan stráví spoustu času prohledáváním LRU seznamů a hledáním malého podílu stránek, které odstranit lze. To může vést k situaci, kde bude vmscan spotřebovávat 100 % času všech CPU; ta situace může trvat hodiny nebo dny a systém vůbec nebude reagovat.

Většina z nás v současnosti nepracuje se systémy o této velikosti; jeden by musel utratit docela dost peněz, aby získal výhody tohoto patologického chování. I tak to ale vypadá jako něco, co by stálo za to opravit.

Řešením je samozřejmě ještě jeden seznam. Když je stránka neodstranitelná, přesune se do zvláštního seznamu neodstranitelných stránek v zóně, takže kód odstraňování stránek ji prostě neuvidí. Protože existuje mnoho způsobů, jak se může stránka stát neodstranitelnou, jádro nebude vždy v době mapování vědět, jestli má být konkrétní stránka v seznamu neodstranitelných, nebo ne. Proto musí mít kód odstraňování stránek při hledání kandidátů ke znovuzískání oči otevřené a když neodstranitelné stránky najde, přesunout je do příslušného seznamu. Zamknuté stránky se v tomto seznamu shromáždí relativně krátce, což kódu odstraňování stránek umožní soustředit se na stránky, se kterými může skutečně něco udělat.

Na mnoho obav, které tato sada patchů vyvolala, bylo reagováno. Několik jich ale zůstává. Některé z nových vlastností vyžadují nové příznaky stránek; těchto příznaků je extrémně málo, takže je vždycky tlak na to, aby se našly cesty, které věci implementují bez jejich spotřeby. Je příliš mnoho konfiguračních voleb a s nimi spojených #ifdef bloků. A tak dál. Vyřešit tyto potíže může chvíli trvat, ale přesvědčit každého, že tyto (dosti důležité) změny ve správě paměti jsou prospěšné za všech okolností, může trvat ještě déle. Takže i když tato sada patchů dělá pokroky, začlenění do 2.6.27 pravděpodobně není na stole.

       

Komentáře

[luky]

Jak je to s tim Nouveau? Nezakazuje nahodou nVidia reverzni inzenyrstvi? (zakazuje)

[eStar]

Podle toho co sem četl se nVidia stavý k projektu Nouveau tak že ho nepodporuje ale ani mu nebude stát v cestě.

[Robert Krátký]

Viz rozhovor: Andy Ritger o vývoji ovladačů NVIDIA.

[petr]

Reverzni inzenyrstvi za ucelem kompatibility je napriklad u nas legalni.

[joe]

Pokud ti dam neco pod nejakou podminkou, tak ji musis dodrzet nebo to nebrat. To snad plati vsude.

Pokud jde o Nouveau, tak nereversuji kod ovladace, ale "sniffuji" data jdouci z/do karty.

[Filip Jirsák]

Pokud ti dam neco pod nejakou podminkou, tak ji musis dodrzet nebo to nebrat. To snad plati vsude.

V právních státech může existovat ještě třetí možnost – ta podmínka je neplatná. Což ještě automaticky nemusí znamenat neplatnost celé smlouvy. V licenčních smlouvách to často bývá explicitně vyjádřeno: pokud je nějaké ustanovení nebo část této smlouvy neplatná, ostatní ustanovení tím nejsou nijak dotčena.

[petr]

Ne, tak to rozhodne neni Divim se, ze jste na to jeste nenarazil (pokud tedy nezijete v jinem state).

[Grunt]

Jak je to s tim Nouveau?

No zatím je to na velice dobré cestě. viz Status Matrix.

2D Podpora je už úplně téměř kompletní(jen na XRENDERu u NV50 se ještě pracuje, ale myslím si, že už bude funkční) a v poslední době se začalo pracovat na 3D(u NV50 už bylo dokonce dokončeno základní vykreslování primitiv) u všech karet od GeForce5200 nahoru a na DualHead u všech karet. Sám jsem ho asi tak měsíc zpátky zkoušel a abych pravdu řekl, když jsem nabootoval tak jsem rozdíl mezi binárním a Nouveau ovladačem nepoznal(I když na GeForce5200 asi ani moc poznat nepůjde). Dokonce mi fungoval i DualHead, jen byly nějaké problémy s rozlišením, tak jsem ho vypnul. Jak by to fungovalo s 3D nevím, jelikož jsem to jen tak zkoušel z repositáře pro Ubuntu a nechtělo se mi kompilovat.

BTW.:Jen mě tak napadá. Když ti KDEčkaři mají pořád takové problémy s verzí 4.1 a nVidia ovladačem, zkoušeli KDE i na Nouveau?

[Jendа]

Jak rychle jsi se začal rýpat v jádře? Na co jsi se díval prvně a proč?

Auuu