Jaderné noviny - 20. 9. 2006

9. 10. 2006 | Robert Krátký | Jaderné noviny | 3816×

Aktuální verze jádra: 2.6.18. Sledovací infrastruktury. Další implementace kontejnerů. nopage() a nopfn().

Aktuální verze jádra: 2.6.18

Aktuální verze jádra je 2.6.18, vydaná 19. září. Určitě si přečtěte oznámení; vypadá to, že v něm jsou i věci, které nepocházejí přímo z gitu. Nová verze přináší spoustu novinek, včetně odvozování priorit, nové obecné IRQ vrstvy, nového časového subsystému, validátoru zámků, SMPnice,úprav virtální paměti, velké aktualizace SATA, odstranění DevFS a mnoha dalších. Vizte stránku LinuxChanges na KernelNewbies, kde je mnohem podrobnější seznam, stránku o změnách API v 2.6 na LWN s informacemi o změnách interních programovacích rozhraní nebo dlouhý changelog.

Aktuální verze -mm stromu je 2.6.18-rc7-mm1. Andrew k vydání poznamenal:

Trvalo snad deset hodin, než bylo možné tuhle hromadu kódu jakž takž zkompilovat, aby se na x86, x86_64 a PPC dobelhala k loginu. Nadšenci mohou testovat.

Také připomněl, že toto jádro nebude fungovat na distribucích se starší verzí udev kvůli změnám v ovladačovém jádře. Mluvilo se o tom v srpnu (nová jádra a staré distribuce). Další změny: "pravděpodobně chybná" změna na API kmap(), které se má starat o otázky koherence, nový parametr GFP_THISNODE pro alokaci paměti, odstranění pochybného ovladače HDAPS bez uvedení důvodu (i když stojí za zmínku, že jeden z posledních patchů pro 2.6.18 dal jasně najevo, že anonymní příspěvky nemohou být přijaty), SLIM a množství oprav.

Pro uživatele 2.6.16: Adrian Bunk 13. září vydal 2.6.16.29 s několika opravami.

Aktuální 2.4 předverze je 2.4.34-pre3, vydaná 19. září. Hlavní změnou je začlenění gcc 4.0 patchů.

Sledovací infrastruktury

Někdy věci prostě nejdou podle plánu. Mathieu Desnoyers je aktuálním správcem Linux Trace Toolkitu, balíku pro sledování jaderných událostí, který - i přes početnou skupinu uživatelů - zůstává už mnoho let mimo jádro. Nedávno vydal novou verzi LTT s následujícím úvodem:

Podle Christophovy rady z letošního léta předkládám menší patch, který by mělo být snazší zkontrolovat, takže snad budou všichni spokojeni.

Výsledkem byla diskuze se stovkami komentářů, z nichž mnohé lze považovat za neslušné i podle měřítek LKML. LTT zjevně odhalil citlivé místo - zvláště překvapivé to je s ohledem na skutečnost, že oblasti sporu jsou minimální.

Čas od času se lidi ptali, jestli jádro vůbec nějaké sledování potřebuje. Tato otázka se zdá být vyřešena (s kladným výsledkem); neshody nyní panují o tom, jestli má být sledování statické nebo dynamické. Statické sledování vkládá do kódu explicitní sledovací body (vypadají jako volání funkcí); sledovací systém pak tyto sledovací body může dle libosti za běhu zapínat nebo vypínat. V dynamickém systému jsou sledovací body do běžícího systému vkládány většinou ve formě přerušovacích instrukcí.

Jádro už má dynamické sledování: KProbes; LTT však používá (především) statický model. Největší otázkou (alespoň na povrchu) tedy je, jestli jádro kromě stávajícího dynamického mechanismu potřebuje ještě balík pro statické sledování. Diskuze se točí kolem několika bodů:

• Režie, část 1: pokud zrovna není sledování využito (normální stav na většině systémů), mají dynamické sledovací body zjevně menší režii: vůbec neexistují. Přes všechno úsilí věnované tomu, aby byly statické sledovací body rychlé, když nejsou využívány, tak tam pořád jsou a vždy budou mít (malou) režii.

• Režie, část 2: pokud sledování využíváno je, bývají statické sledovací body rychlejší. Přerušovací mechanismus, který (v současné implementaci) využívají KProbes, si vezme přibližně desetkrát více cyklů procesoru než statický sledovací bod. Existují projekty (především djprobes), které mohou tuto režii výrazně snížit. V rámci diskuze poslal Ingo Molnar sérii patchů, které snižují režii KProbes zhruba na polovinu.

  Proč se v takovém případě starat o režii? Sledování se mnohdy používá ke zkoumání častých událostí, takže větší počet sledovacích bodů může věci znatelně zpomalit. Jde však hlavně o to, že těžkopádné sledovací body mohou změnit načasování událostí, což vede k obávaným "heisenbugs", které zmizí v okamžiku, kdy je vývojář začne hledat.

• Režie správy: někteří vývojáři mají obavy, že by přidání statických sledovacích bodů zkomplikovalo správu kódu. Sledovací kódy samy o sobě kód zahušťují a navíc musí fungovat provždy. Každý z nich by si šlo představit jako malé systémové volání, které se po umístění nesmí měnit. Vývojáři se také obávají, že by v budoucnu mohly přicházet požadavky na přidávání dalších bodů.

  Na druhou stranu, dynamické sledovací body znamenají jiný druh režie: každý, kdo potřebuje určitou skupinu bodů, se musí starat o jejich správu. Při změnách jádra se budou muset měnit i body, aby tyto změny odrážely. Udržovat dynamické sledovací body aktuální může být velmi složité a namáhavé. Nástroje jako SystemTap v tomto ohledu pomáhají, ale zdaleka se v současnosti nejedná o kompletní řešení. Naproti tomu statické sledovací body umístěné v jádře budou fungovat i při změnách kódu.

• Pružnost: dynamické sledovací body lze umístit kdykoliv a kamkoliv, kdežto statické vyžadují přinejmenším editaci kódu, rekompilaci a restart. Dynamické sledovací body mohou také snáze podporovat filtrování událostí za běhu. Statické jsou zase lepší při přístupu k lokálním proměnným.
• Podpora architektur: KProbes v současné době nejsou na všech architekturách implementovány, takže nejsou dostupné všem uživatelům Linuxu. Statické sledovací body obvykle nevyžadují tolik fíglů specifických pro jednotlivé architektury, takže je snazší je univerzálně podporovat. Mluvilo se však také o tom, že začleněním statických sledovacích bodů by správci architektur ztratili motivaci ke zprovozňování KProbes.

Dá se pochopit, že si člověk při pročítání diskuze začne zoufat. Kupodivu je však množství neshod nižší, než by se zdálo. Účastníci se skoro shodují v tom, že existuje uplatnění pro obojí - statické i dynamické sledovací body. Statické sledování událostí pomůže mnoha lidem porozumět tomu, co se v systému děje - nejen vývojářům jádra, ale i vývojářům uživatelských aplikací a systémovým administrátorům. Chtít po těchto všech, aby zjišťovali, kam vložit například sledovací bod pro hlášení změn scheduleru v konkrétním jádře by bylo mnohem těžší.

Klíčové je však to, že hodnota statického bodu není ani tak v jeho statickém umístění, ale v tom, že ukazuje, kde by měl sledovací bod být. Proto bylo navrženo řešení, které by mělo být přijatelné pro všechny - vložit místo sledovacích bodů "značky". Tyto značky, které by byly v jiné části obrazu jádra, jsou pouhými záložkami ukazujícími, kam by měly být v případě potřeby vloženy dynamické sledovací body. Mathieu k tomu účelu poslal jednoduchý značkovací patch; rychle se dostal pod palbu kvůli implementačním otázkám, ale jen málo lidí bylo vyloženě proti takovému nápadu.

Takže značky možná budou tím krokem vpřed. Pokud by mohl být kód LTT přepracován podle konceptu značek, mohlo by to otevřít dveře diskuzi o tom, co ještě je potřeba udělat, než bude kód začleněn (je tu několik problémů, které byly až doposud zastíněny stávající debatou). Po odpovídajícím zvážení by do jádra mohla být přidána pečlivě vybraná sada značek/sledovacích bodů, což by všem umožnilo se napojit a monitorovat události. Až opadnou vášně, mohlo by z toho být řešení, se kterým budou souhlasit skoro všichni.

Další implementace kontejnerů

Kontejnery se už přibližně rok těší zvýšené pozornosti vývojářů. Koncept kontejnerů nabízí mnohé z předností plné paravirtualizace, ale za mnohem nižší cenu, což umožňuje spuštění více virtuálních strojů na jediném hostiteli. Jediným problémem je všechny přesvědčit o tom, co to vlastně ten kontejner je. Nedávná kontejnerová sada patchů od Rohita Setha je dalším pokusem, jak tomuto konceptu dát tvar.

Mnohé přístupy ke kontejnerům se točí kolem stromu procesů - jeden proces se uzavře do kontejneru a stane se v něm "init" procesem; kontejner je pak zaplněn potomky původního procesu. Rohitův patch část této funkčnosti zachovává - když proces zavolá fork(), bude potomek náležet stejnému kontejneru jako předek (je-li nějaký). Mechanismus je však ještě trochu pružnější. Do kontejneru mohou být kdykoliv přidány - nebo z něj odebrány - libovolné procesy.

Takové změny se provádí prostřednictvím rozhraní configfs. Je-li configfs připojen do /config, může administrátor systému s kontejnery pracovat v /config/containers. Nový kontejner se založí vytvořením nového adresáře; kontejnery jsou tedy identifikovány pomocí jednoduché jmenné struktury. Adresář kontejneru obsahuje několik souborů:

• addtask: zapsání ID procesu do tohoto souboru způsobí přidání příslušného procesu do kontejneru. Procesy, které už patří nějakému kontejneru, nemohou být do nového kontejneru přidány jen tak; nejprve musí být odstraněny ze starého kontejneru.
• rmtask: odstranit proces lze zapsáním ID do tohoto souboru.
• page_limit: maximální počet aktivních stránek paměti, které může kontejner použít.

Pak ještě několik informačních souborů pro získávání statistik o provozu kontejneru.

Paměťový limit funguje pomocí přidání kontejnerového ukazatele do každé struktury mm_struct a address_space v systému. Jak dochází k uvolňování nebo zabírání stránek, je aktualizováno i počítadlo kontejneru. Pokud kontejner svůj limit přesáhne, pustí se do práce samostatný proces (pracovní fronta), který uvolňuje stránky patřící kontejneru. Je-li limit překročen o hodně, budou procesy v rámci kontejneru na okamžik pozdrženy (když se pokusí přidat stránky), aby likvidátor nezůstal pozadu.

Rohitovy kontejnery se tedy starají o ovládání souhrnného využití zdrojů. V tomto smyslu připomínají cifršpióny zdrojů - i když žádný kód z toho patche nevyužívají. Tyto kontejnery také postrádají jednu funkci, kterou lze nalézt ve většině jiných implementací: nějaký způsob kontroly jmenných prostorů. Procesy umístěné do jednoho z těchto kontejnerů i nadále vidí celý systém - a budou k němu mít přístup.

Takže jde jen o částečné řešení problému - alespoň z tohoto pohledu. Funkce pro kontrolu jmenného prostoru by patrně mohly být přidány později, i když by bylo zajímavé vidět, jak by taková kontrola spolupracovala s možností kdykoliv přidávat nebo odebírat procesy.

nopage() a nopfn()

nopage() je operace s adresními prostory, která se má starat o velké chyby stránek v daném adresním rozsahu. Pro adresní prostory se zálohou v souborech existuje obecná nopage() metoda, která zajistí načtení potřebných stránek do paměti. Ovladače zařízení také občas poskytují nopage() coby součást své implementace mmap(). V případě ovladačů je chyba stránky většinou řešena nalezením struct page odpovídající bufferu mapovanému do paměti a předáním výsledku zpátky jádru.

nopage() může signalizovat dvě chyby: NOPAGE_SIGBUS u skutečně špatných adres a NOPAGE_OOM u situací, při kterých OOM (nedostatek paměti) způsobil selhání pokusu o řešení chyby. Chybí však možnost dát najevo, že byla nopage() přerušena signálem a operace by se měla zkusit znovu. Taková situace většinou nenastává, protože pokud musí nopage() čekat, většinou je to provedeno tak, aby operaci nešlo přerušit. Benjamin Herrenschmidt však na tento problém narazil a navrhl malou změnu, která by přidala novou hodnotu NOPAGE_RETRY. Reakce by byla předvídatelná - opětovné spuštění operace po zpracování signálu.

Ukázalo se, že Google podobný patch má pro svou interní potřebu, i když důvody použití jsou jiné. V případě Google slouží patch k odstranění problému s výkonem. Patch nebyl navržen k začlenění kvůli možným potížím s DoS a také proto, že jej jeho autor považuje spíše za hack.

Je možné, že nakonec bude patch v nějaké podobě začleněn, ale nejprve je nutné na něm zapracovat. Oba patche ukazují, že k vracení NOPAGE_RETRY je více důvodů, takže by dávalo smysl je zpřístupnit vyšší úrovni zpracovávače chyb stránek. To by umožnilo odstranění některých potenciálních problémů s efektivitou, ale i nadále je tu hrozba možného DoS útoku.

Při té příležitosti se mluvilo o dlouho známém omezení nopage(), které spočívá v tom, že může řešit jen situace, kdy má příslušná fyzická paměť odpovídající struct page. Tyto struktury existují u hlavní paměti, ale ne pokud je paměť například na periferním zařízení a mapovaná do PCI I/O paměťové oblasti. Některé architektury také provádějí velmi podivné věci se speciální pamětí a vícenásobnými pohledy na tu samou paměť. V takových případech musí ovladače paměť explicitně namapovat do uživatelského prostoru pomocí remap_pfn_range() místo použití nopage().

Jes Sorensen má už nějakou dobu připravený patch, který přidává další operaci s adresním rozsahem: nopfn(). Je volána v reakci na chyby stránek, není-li k dispozici žádná operace nopage(); má za úkol vrátit fyzickou adresu (jako číslo rámce stránek) stránky, což chybu napraví. Adresa bude uložena přímo do tabulky stránek procesu, přičemž není potřeba žádná struct page a neprovádí se počítání referencí. Jes napsal ovladač speciální paměti pro IA-64, který demonstruje využití této operace.

V minulosti nebyla tato věc příliš populární - Linus je proti, stejně jako další. Někteří to považují za komplikování subsystému virtuální paměti; ti by byli raději, kdyby se v kódu používala remap_pfn_range() nebo se podle potřeby vytvořily speciální page struktury. Je však několik situací, ve kterých prý nopfn() funguje lépe, a tlak na začlenění neustupuje. Bude tedy zajímavé sledovat, jestli se dostane do 2.6.19 nebo ne.

       

Komentáře

[Nikola Ciprich]

bezva bezva, jen houst a vetsi kapky

[CIJOML]

Proboha už se vykašlete na nějaké české zhovadilé názvosloví!!! Cifršpión to je jako pěšnoved???

[Lukáš Zapletal]

Nádhera, jen víc... Tady jsme uprostřed Evropy.

[Robert Krátký]

Cifršpión to je jako pěšnoved???

Nikoliv. Přečti si článek, na který to odkazuje. Zjistíš, že žádné nové názvosloví nezavádím. Pro "resource beancounters" používám v textu anglický pojem "beancounter", aby to nebylo matoucí. Zároveň však chci přiblížit, oč se jedná, a proto jsem si dovolil to i přeložit.

[Nikola Ciprich]

nj, nic to ale nemeni na tom ze to zni naprosto odporne. jinak ale diky za clanek, jaderne noviny rozhodne jsou moje nejoblibenejsi ctivo na abcl ;)

[Robert Krátký]

To je asi věc názoru. Znáš jiný (hezčí) slangový výraz pro "účetní".

[walley walleyovic]

ucetni potrebuje slangovy vyraz? termin cifrspion jsem v zivote neslysel a netusim co to je:) mozna tanejotravnejsikanclkrysa;)))) by se hodil vic ... ted me vsecky ucetni asi sezerou

[Robert Krátký]

ucetni potrebuje slangovy vyraz?

Má-li být překlad aspoň trochu věrný... Nepřekládáme "accountant", nýbrž "beancounter".

termin cifrspion jsem v zivote neslysel

Škoda. A takové je to pěkné slovo. I Google o něm už párkrát slyšel...

[xkesh]

termin cifrspion jsem v zivote neslysel a netusim co to je:)

Náhodou skvělý překlad! Proč snižovat laťku kvůli ignorantům? Tohle slovo má v češtině dost dlouhou tradici. A i tomu, kdo ho ještě neslyšel, protože má omezené obzory, by mohlo při troše kombinačního úsilí dojít, co znamená. Samozřejmě vyjímám lidi před pubertou a bez fantazie, k čertu s nimi :P

[Michal Kubeček]

Není cifršpión spíš nějaký kontrolor, revizor nebo auditor než klasický účetní?

[xkesh]

Není cifršpión spíš nějaký kontrolor, revizor nebo auditor než klasický účetní?

Ne ;)

[Filip Jirsák]

Mně se cifršpión líbí – s jiným termínem to nekoliduje a anglický originál se do češtiny (zatím) nepřejal, tak nevidím důvod, proč to nepoužít.

[T.]

Cifršpion je slovo který už sem já jako malej slyšel od svýho dědy a ten dělal celej život účetního v různejch bankách Takže je to zcela určitě hodně starý český slovo dědovi bylo 86 a už tu neni :(

[Filip Jirsák]

Jj, ale jde o to, že nekoliduje s jiným termínem z IT. Pokud je někdo účetní a zároveň Linuxák, musí se holt přepnout na správný kontext

[Vykook]

Myslim ze od dnesniho rana ziskavaji Jaderne noviny zcela novy rozmer

[Jan Včelák]

Co to je za Jaderne noviny, kdyz tu neni ani zminka o KLDR?

[xkesh]

Co to je za Jaderne noviny, kdyz tu neni ani zminka o KLDR?

jakože KDE loader? :P

[Michal Kubeček]

Není teď v módě spíš Írán?

[jozka]

Od vcrejska mame (alespon na chvili) jinou hvezdu.