9.10.2006 01:16
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
Rozbalit Rozbalit vše kontejnery a podpora virtualizace
Portál AbcLinuxu, 7. května 2025 09:55
Aktuální verze jádra: 2.6.18. Sledovací infrastruktury. Další implementace kontejnerů. nopage() a nopfn().
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ů.
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 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.
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.
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ů:
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() 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.
9.10.2006 01:16
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
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.
9.10.2006 09:19
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
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...
Takže je to zcela určitě hodně starý český slovo 
dědovi bylo 86 a už tu neni :(
9.10.2006 21:08
Vykook | skóre: 23
| blog: Tomas
Co to je za Jaderne noviny, kdyz tu neni ani zminka o KLDR?jakože KDE loader? :P
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
9.10.2006 08:31