Jaderné noviny – 27. 1. 2010

18. 2. 2010 | Jirka Bourek | Jaderné noviny | 3322×

Aktuální verze jádra: 2.6.33-rc5. Citáty týdne: Linus Torvalds, Thomas Gleixner, Al Viro. Modul pro shazování jádra. fincore(). LCA: Poníci – grafické ovladače.

Obsah

• Aktuální verze jádra: 2.6.33-rc5
• Citáty týdne: Linus Torvalds, Thomas Gleixner, Al Viro
• Modul pro shazování jádra
• fincore()
• LCA: Poníci – grafické ovladače

Aktuální verze jádra: 2.6.33-rc5

Současné vývojové jádro je 2.6.33-rc5 vydané 21. ledna. Obsahuje mnoho oprav, tempo patchů přicházejících do 2.6.33 je stále poměrně vysoké.

Ve vývojovém jádře 2.6.33-rc5 zůstává 23 nevyřešených regresí (ze 75 nahlášených).

Stabilní aktualizace: 2.6.32.5 bylo vydáno 22. ledna, následováno 2.6.32.6 z 25. ledna; obě obsahují poměrně hodně důležitých oprav. 2.6.32.7 je revidováno v době psaní tohoto článku; obsahuje 98 oprav a lze ho očekávat někdy po 28. lednu.

Citáty týdne: Linus Torvalds, Thomas Gleixner, Al Viro

Takže můžu pracovat s bláznivými lidmi, v tom problém není. Jenom mi musí svoje bláznivé věci prodat s použitím nebláznivých argumentů, a to po malých a dobře definovaných kouscích. Když chci zabijácké vlastnosti, chci, aby mě nejdřív ukolébali do bezpečného a útulného světa, kde je ta věc, kterou tlačí dovnitř, užitečná lidem od hlavní řady.

Jinými slovy, každá nová bláznivá vlastnost by měla být schována v dárkovém balení jako „trojský kůň“: Musí vypadat jako něco na první pohled zjevně dobrého.

-- Linus Torvalds

Tohle má jenom jedno rozumné řešení: Nepoužívej kgdb – což je modus operandi každého příčetného jaderného vývojáře na planetě.

-- Thomas Gleixner

OK… lookup_instantiate_filp() je příšerný bordel, takže je v pořádku být tím zmaten – její autor rozhodně byl.

-- Al Viro

Modul pro shazování jádra

Normálně je jádro, které nepadá, považováno za dobré jádro. Může ale také být zdrojem opravdové frustrace pro ty, kteří chtějí vidět, jak systém letí v plamenech k zemi. Spolehlivost systému znamená, že člověk čekající na pád může při čekání zestárnout.

Simon Kagstrom zaslechl o problémech takových uživatelů; proto zaslal jaderný modul pro ty, kdo si chtějí sestřelit systém na vyžádání. Tento modul vytvoří v debugfs adresář (provoke_crash [vyprovokuj_pád]), ve kterém je několik užitečných souborů. Pro ty, kdo mají jednoduché požadavky, zápis do bugon vyústí v přímočaré volání BUG(). Uživatelé s jemněji vytříbeným vkusem mohou zapsat do null_dereference a tím způsobit dereferenci nulového ukazatele, overwrite_allocation zapíše za alokovanou haldu [heap], corrupt_stack přepíše zásobník. Opravdu výstřední uživatelé mají k dispozici i oops_interrupt_context dereferencující nulový ukazatel v režimu softirq, write_after_free, který šlápne do uvolněné paměti, či unaligned_load_store, který provede špatně zarovnané operace s pamětí.

Není potřeba říkat, že toto není modul, který by někdo chtěl nechat nahraný v jádře na produkčním systému; lepší je držet ho na tajném místě a vytáhnout, až když děti spí. Samozřejmě kromě případů, kdy pro něj máte skutečné využití; Simon ho používal k tomu, aby kmsg_dump() dělala v různých případech pádu správnou věc. U většiny vývojářů je nicméně práce řízena potřebou pádům se vyhýbat; protože pro tuto vlastnost nemají využití, není jasné, jestli se tento malý modul někdy dostane do hlavní řady.

fincore()

Linux má již dlouho systémové volání mincore(), které aplikaci umožňuje zjistit, jestli je daná stránka v RAM, nebo ne. Není ale snadné zjistit, jestli je daná stránka ze souboru v cache stránek, nebo ne. Aplikace může soubor namapovat pomocí mmap() a použít mincore(), ale to může být pomalé. Christ Frost proto navrhl nové systémové volání fincore(), které by to zajistilo:

int fincore(int fd, loff_t start, loff_t len, unsigned char *vec);

Volání fincore() se podívá na stránky souboru spojené s fd v rozsahu určeném start a len. Pro každou stránku v souboru je jeden byte ve vec nastaven na nenulovou hodnotu, pokud je tato stránka v paměti. Odpověď je přirozeně pouze přibližná – situace se během běhu systémového volání může změnit.

To nicméně může být pro Chrisovy potřeby dostatečně dobré. Jeho cílem je zrychlit aplikace, které provádí mnoho nesekvenčních čtení ze souboru. Tradiční kód dopředného čtení se s takovou situací vyrovnává špatně, vzhledem k tomu, že vzor přístupů nelze předem odhadnout. Aplikace ale často dopředu zná sekvenci, ve které bude číst; pokud by bylo možné jádru říci, aby tyto stránky natáhlo předem, mohlo by řadit I/O operace optimálně a celou věc zrychlit. Když to udělal u sqlite a GIMPu, hlásil Chris významné zrychlení.

Přednačtení dat lze vyžádat systémovým voláním fadvise(). Je tu ale problém: Pro přednačítací knihovnu je těžké zjistit, kolik je k dispozici systémové paměti. Pokud je přednačteno příliš málo dat, výkonnostní zisky nebudou takové, jaké by mohly být; přednačtení příliš mnoha dat však může vést ke značnému zpomalení. A proto systémové volání fincore(): Jestliže přednačtené stránky nejsou k dispozici, když se aplikace dostane k tomu, že je chce použít, knihovna ví, že chtěla příliš a že by měla zpomalit.

Andrewu Mortonovi se patch líbí:

Musím říct, že toto systémové volání se líbí geekovi ve mně. Spousta aplikací plýtvá časem kvůli špatným vzorům přístupu k disku. Opravdu chytrá knihovna, která by takový nástroj používala, by mohla leckde pomoci.

Jamie Lokier se ale ptal, jestli by nebylo lepší najít způsob, jak aplikace informovat o tom, že jsou jejich stránky odstraněny před použitím.

Jde o první zaslání tohoto systémového volání, takže se mu nedostalo příliš pozornosti; určitě bude nutná delší diskuze, než ho bude možné začlenit. Více informací najdete na stránce o libprefetch.

LCA: Poníci – grafické ovladače

Ti z vás, kteří mají rádi prezentace Davea Airlieho plné koťátek, byli dost možná nespokojeni s jeho přednáškou na linux.conf.au, která byla nazvána "Tak jste přestěhovali grafické ovladače do jádra… a co teď? Můžu mít poníta?" Poníci ale také mohou být hezcí a shrnutí novinek ohledně stavu grafických ovladačů v jádře stálo za to si vyslechnout.

Nyní je to přibližně rok od doby, co bylo do hlavní řady začleněno jaderné nastavování režimu [kernel mode setting, KMS]. KMS ukončuje ten „nepořádek“, který vzešel z toho, že grafické ovladače byly v uživatelském prostoru; vykopat se z této jámy trvalo dobrých sedm let. Teď jsou grafické ovladače v jádře stejně jako většina ostatních.

Kromě vyklizení tohoto zmatku je několik dalších dobrých důvodů pro začlenění KMS. Jedním z nich je, že systém je nyní plně schopen využít možnosti úspory energie hardwarem; před KMS jádro nikdy nevědělo, co se s hardwarem děje. Co se týče úspory energie, ovladače od Intelu mohou nyní fungovat stejně dobře jako na Windows; ovladače od ATI tak daleko ještě nejsou. Další hezká vlastnost je možnost použít jaderný debugger na systému, na kterém běží grafika; nyní je možné odskočit do debuggeru a pak se vrátit do běžícího systému a vše bude fungovat.

Jediný důvod, proč tak dlouho trvalo KMS začlenit, bylo to, že od jádra vyžaduje spoustu nových věcí. Na začátku seznamu je slušný správce grafické paměti. To je složitý problém, takový, kterému se vývojáři grafiky chtěli věnovat někdy Opravdu Brzy. Nakonec se k tomu dostali vývojáři TTM, ale ti rychle narazili na mnoho problémů s API. Po nějaké snaze se vývojáři od Intelu rozhodli, že obecný přístup k API správy paměti nebude fungovat; z toho vzešel správce paměti GEM, který se pokoušel řešit problém jenom u Intelu.

Vývojáři pracující na čipových sadách ATI následně brzy zjistili, že GEM nemá možnosti, které potřebují. Proto se vrátili zpět k TTM, ale ne předtím, než na něj našroubovali něco, co vypadá jako API GEM. TTM byl nedávno začleněn, takže KMS je možné použít u čipových sad ATI.

Co nás tedy čeká? Jedna z budoucích vlastností je architektura Gallium 3D. Gallium, jak říká Dave, začíná fungovat, ale ještě bude chvíli trvat, než bude plně funkční. Úprava ovladačů pro Gallium bude nepříjemné cvičení; již teď existuje několik API, která je potřeba podporovat. Také se blíží DRI2; tato vlastnost je nutná k tomu, aby KMS fungovalo správně, obzvláště u kompozitních záležitostí. Stále jsou ale výkonnostní problémy, které je potřeba vyřešit.

Další věc, na kterou se můžeme těšit, je zobrazovací server Wayland. Wayland lze považovat za jednodušší a menší náhradu X vystavěnou nad KMS. Nyní na něm mohou běžet GTK a GL aplikace; také pro něj existuje emulátor X serveru. Zbývá několik potíží včetně toho, že Wayland není X; vzhledem k tomu, že X je v dané oblasti standard, alternativy bude obtížné prodat. Vývojáři Waylandu se také ještě nepotýkali s problémem vstupu, přičemž to je velký kus kódu X. Wayland tedy také bude ještě chvíli na cestě; možná se dostane nejprve do embedded řešení.

Dave věnoval nějaký čas současnému stavu grafických ovladačů. Intel, jak řekl, je v současnosti ve vedení. Podporuje KMS všude – dobrá, téměř všude; „čipová sada, o které nemluvíme“ (proprietární GMA500) podporu stále postrádá. Ovladač obsahuje všechny vlastnosti, ale Dave ho nechce nazývat „dokončený“; na to bude potřeba ještě jedno nebo dvě vydání. Jak zde bylo dříve zmíněno, ovladač bude muset nějakou dobu udržovat nastavování režimu z uživatelského prostoru [user mode setting, UMS], nicméně současné zdrojové kódy X.org v upstreamu již podporu UMS z X serveru vyřadily.

Ovladače ATI/AMD jsou trochu více pozadu, ale blíží se; vzhledem k mnoha variacím čipových sad je tento ovladač složitější než ovladač Intelu. V současnosti jsou podporovány čipové sady od R100 do R700; Podporu R800 lze očekávat během několika týdnů. Ovladač aktuálně funguje „skoro tak dobře jako ten starý“; uspávání a probouzení fungují lépe než dříve. Podpora úspory energie chybí, ale očekává se v 2.6.34. Ovladač Radeon je v současnosti ve stromě -staging, ale z toho se může dostat před koncem vývojového cyklu 2.6.33.

Co ovladač RadeonHD? Oddělení tohoto ovladače je primárně důsledkem neshody ohledně používání tabulek BIOSu ATI; ovladač Radeon obsahuje interpreter těchto tabulek, zatímco RadeonHD reimplementuje funkce, které tyto tabulky poskytují. Používání tabulek BIOSu značně ulehčuje práci; umožňuje to ovladači ignorovat mnoho detailů spojených s různými variantami čipových sad. Kód pro tabulky BIOSu je součástí implementace KMS, která byla začleněna do hlavní řady; to by podle Davida mělo neshody vyřešit.

„Poník“ zobrazený u zmínky o Nouveau byl ve skutečnosti Trojský kůň. Nouveau bylo samozřejmě začleněno do 2.6.33. Ovladač právě ztratil svoji podporu pro nastavování z uživatelského prostoru; umí pouze KMS. Podporovány jsou čipové sady od NV4 po G80 a poslední kousky budou brzy doplněny. Firmware „ctxprogs“ je zkoumán; verze pro NV40 byla již nahrazena přepsaným ekvivalentem se svobodnou licencí a u NV50 se na tom pracuje. Dave poznamenal, že ať už si lze o spolupráci nvidie s komunitou myslet cokoliv, jejich hardware bývá relativně dobrý a snadno se s ním pracuje.

Když byl Dave dotázán na podporu nelinuxových systémů, odpověděl, že většina z nich byla ponechána svému osudu. U Sunu se zjevně pracuje na portu pro OpenSolaris, ale tato skupina nevydala žádný kód. Další člověk z publika se zeptal na běh X bez oprávnění roota: To nyní funguje a Moblin to používá. Zbývá ale několik problémů, obzvláště co se týká rychlého přepínání uživatelů. Vzhledem k absenci systémového volání revoke() nelze nijak garantovat, že nějaký uživatel neodposlouchává jiného. Protože je revoke() obtížný problém, není jisté, jak bude tato záležitost vyřešena.

       

Komentáře

[Mandarinka]

Jenom rýpnutí: když je řeč o grafikách, tak tím "chipset" pisatel na beton nemyslí čipovou sadu, ale prostě čip. Ať už je důvod jakýkoliv, angláni to tak prostě říkají... a nejen o grafikách, ale i o různých řadičích atp. Nicméně čip je tu jenom jeden, tak by se to mělo zohlednit a nepřekládat doslova.

[trekker.dk]

Hm, když na to nezapomenu...

[thingie]

No, stylisticky.

Je tu jeden překlep z poníka na poníta.

„Musím říct, že toto systémové volání se líbí geekovi ve mně.“ Tohle mi přijde úplně hrozné. Hotová hotentotština. Nejsem si docela jistý proč. Ale zní to příšerně nečesky.

A třeba i jednoduché požadavky trochu smrdí. To by člověk česky neřek.

[Robert Krátký]

Je tu jeden překlep z poníka na poníta.

Není to překlep.

[thingie]

Aha, no, qwerty-distance mi mohla být podezřelá, pravda. Zajímavý překlad I can haz. :)

[trekker.dk]

Je tu jeden překlep z poníka na poníta.

To není překlep.

[cronin]

Mozete to vysvetlit? V originali je "ponies".

[Jakub Lucký]

Je to "simulace" dětské neprecizní artikulace a větné stavby, aby se dostálo původnímu textu, který simuluje tentýž děstký vyjadřovací nedostatek

[Jakub Lucký]

*dětský, ne děstký... pardon

[Semo]

Mam pocit, modul provoke-crash pre zhadzovanie jadra je uz aspon 2 roky sucastou "stabilnej" rady.

[trekker.dk]

Jak přesně to projevuje? (Nebo jinak: nebude to rukama?)

Například s jádrem 2.6.31 jsem měl na desktopu uptime 55 dní. Ten jsem ukončil upgradem na 2.6.32, žádný pád.

[R]

No ja mam s 2.6.30 uptime desktopu mesiac (s hibernaciou). Ale s 2.6.31 po par hibernaciach zacnu padat spustene programy. 2.6.32 to iste. Este som sa nedokopal k bisectu, lebo to bude po****t roboty.

[trekker.dk]

Těch 55 dní na 2.6.31 je s hibernací. 2.6.32 mám jenom pár dní.

[Nikola Ciprich]

proc? jestli se problem da vyvolat prakticky hned, tak bisect je celkem rychlovka...

[Semo]

Jadra 2.6.27 <= verzie <= 2.6.31 hadzali deterministicky oopsy pri odmountovani fs mountovanom s -o loop. Ostavali potom procesy v stave D a neslo uz dalej mountovat loopy. Robit na takom jadre s obrazmi diskov z VirtualBoxu je fakt radost.

Sietovka via-rhine nevydrzi pracovat ani 24h a ostane az do rebootu nenastartovatelne spadnuta. Sachovanie s vyhodenim/nahodenim modulu nepomaha. Tato sietovka je sice velmi pravdepodobne spraseny kus hw, ale existovalo okno jadier cca od 2.6.18 po 2.6.26, kedy fungovala. V starsich a novsich verziach uz pada.

2.6.32 vyzera vynimocne dobre, pokial ho bootujem s nolapic_timer (kvoli tej sietovke). Chapem, ze nemam prave rockstable hw od IBM, ale uz to kedysi chodilo bezproblemovo.

[trekker.dk]

Jadra 2.6.27 <= verzie >= 2.6.31 hadzali deterministicky oopsy pri odmountovani fs mountovanom s -o loop. Robit na takom jadre s obrazmi diskov z VirtualBoxu je fakt radost.

S loop jsem si nedávno na 2.6.31 užíval docela dost. Ani jeden oops. A stěžovat si na jádro, když do něj cpeš binární sra?ky...

[vlastikroot]

Asi tak, loop používám skoro furt a nikdy se mi nic nepřihodilo. Asi by mě to fakt naštvalo, taková základní část jádra.

[Semo]

binární sra?ky...

WTF???

tusim to chcelo viac loopov simultanne alebo tak nejak, pripadne nejaky bind na miesto, ktore je fyzicky na loope. A robila to aj vanilla (ked uz som zacal podozrievat Gentoo tym, tak som skusal aj vamillu; Gentoo team je nevinny).

[petr_p]

Něco tam bude shnilého. Mě v novějších jádrech nefunguje swapování do šifrovaného loopu.

[Jendа]

A stěžovat si na jádro, když do něj cpeš binární sra?ky...

VirtualBox má i opensource edici a ten jaderný modul je AFAIK otevřený vždy.

[Semo]

Ahaaaa, uz som pochopil, co si myslel tymi binarnymi srackami. Ak jadro pada, pretoze na disku (nie v pamati) je modul ku VB, tak je zhnite. S imagmi som sa hral prave preto, aby som mohol pristupovat ku fs z virt. stroja aj bez VB.

Ku zasekavaniu sietovky via-rhine vysiel patch zaradeny do 2.6.33, ktory by mal opravovat prepinanie nejakeho modu sietovky (to prepnutie sa spravne, iba ak je sietovka v nejakom mode, a stary kod to nerespektoval, novy by mal). Ale nezabera to. Teda prinajmensom ten patch nepomaha do 2.6.32. Aplikoval sa bez kecov, ale problem neriesi. Pockam na 2.6.33, ale vidi to bledo.