31.1.2011 11:13
atan | skóre: 21
| Liberec
Rozbalit Rozbalit vše Re: Jaderné noviny – 19. 1. 2011: Jak pomáhá linux-next při vývoji
Portál AbcLinuxu, 29. května 2024 01:22
Aktuální verze jádra: 2.6.38-rc1. Citáty týdne: Matthew Garrett, David Woodhouse. Obcházení linux-next. Začleňovací okno 2.6.38, část druhá. Transparentní velké stránky v 2.6.38.
Současné vývojové jádro je 2.6.38-rc1, vydáno bylo 18. ledna. Jsou to dva týdny a začleňovací okno 2.6.38 se tedy zavírá. A rozhodně bylo zajímavé. V tomto cyklu bylo začleněno těsně nad 7 600 změn. Některé z nich poměrně invazivně ovlivňují základní kód a již byly nahlášeny poměrně významné regrese. Lidé testující 2.6.38-rc1 by měli být o něco opatrnější (a mít lepší zálohy) než obvykle. Všechny detaily vizte v kompletním changelogu.
Stabilní aktualizace: Během tohoto týdne žádné nevyšly.
napsal Jonathan Corbet, 19 ledna 2011
Od vytvoření stromu linux-next uběhly téměř tři roky a během té doby se stal nepostradatelnou součástí vývojového procesu. Když je kód začleněn do hlavní řady, byl předtím testován, co se integrace a překladu týče, v linux-next; v některých případech je dokonce testováno i použití. To napomohlo tomu, že začleňovací okna probíhají o něco více hladce. Není tedy překvapením, že vývojáři jsou číl dál tím více nabručení, když nějaký kód linux-next obchází a vytváří problémy v hlavní řadě.
V cyklu 2.6.38 jsme viděli několik příkladů. Když Al Viro zaslal svůj první požadavek na přetažení VFS, stěžoval si správce linux-next Stephen Rothwell, že tento kód vidí poprvé, přestože zjevně existuje již několik měsíců. Al je známý tím, že příspěvky do hlavní řady stíhá na poslední chvíli, takže to nebylo tak překvapující; uvidíme, jestli ho bude možné přesvědčit, aby své postupy změnil.
Další stížnost přišla po začlenění sady patchů transparentních velkých stránek [transparent huge pages], které přišly přes strom -mm Andrewa Mortona. Tony Luck, který zjistil, že hlavní řadu najednou nejde přeložit pro ia64, se zeptal:
Andrew odpověděl, že to chce čas – se Stephenem probíráme plán. Integrace -mm vždy byla a bude trochu problematická; linux-next má obsahovat kód, který je připraven k začlenění do hlavní řady, zatímco v -mm může léta být kód ve vývoji. Dokud to nebude vyřešeno, vývojáři správy paměti budou v trochu obtížné situaci; nemají k dispozici žádný správcovský strom [maintainer tree], kam by mohli začlenit svůj kód a odkud by byl začleněn do linux-next. Tito vývojáři budou do linux-next muset buď zasílat své vlastní stromy (což je jednoduché), nebo přijmout stížnosti, když kód, který žil v -mm, vidí testeři v době začlenění do hlavní řady poprvé.
napsal Jonathan Corbet, 19 ledna 2011
V době vydání 2.6.38-rc1 bylo do hlavní řady přetaženo nějakých 7616 neslučovacích sad změn. Od shrnutí z minulého týdne bylo začleněno mnoho významných úprav; nejzajímavější z těch viditelných pro uživatele jsou:
Byly začleněny transparentní velké stránky [transparent huge pages, THP]. THP se snaží maximalizovat používání velkých stránek v systému (což zvyšuje výkonnost), bez nutnosti měnit aplikace nebo něco nastavovat.
Byl přidán nový nástroj turbostat; lze ho použít k získání různých výkonnostních statistik z procesorů Intel. Také byl přidán x86_energy_perf_policy, který umožňuje ladit výkonnost/spotřebu procesorů Intel.
API taskstats bylo změněno tak, že jinak zarovnává vrácené hodnoty; to může rozbít aplikace, které závisí na starém uspořádání.
Jádro nyní může s vysokou přesností synchronizovat svůj interní čas podle externího signálu pulzy-za-sekundu [pulse-per-second, PPS]. Jádro také získalo možnost generovat (a přijímat) PPS signály na paralelním portu, tedy za předpokladu, že někdo ještě najde počítač, na kterém takový port bude.
Architektura x86 nyní může bootovat jádra komprimovaná pomocí XZ.
Do vrstvy zařízení pro vstup od uživatele [human input devices, HID] byla začleněna základní podpora pro vícedotykové panely.
Jádro nyní obsahuje podporu pro šifrovací algoritmus RFC4106 AES-GCM.
Systémové volání fallocate() lze nyní využít k vyrážení děr do prostředka souborů. Tuto vlastnost v současnosti podporují XFS a OCFS2.
Souborový systém XFS podporuje ioctl() FITRIM, což umožňuje vyvolat z uživatelského prostoru zahazovací operace. Není to určeno pro volání během normální zátěže, protože procházky b-stromem volného prostoru mohou způsobit vážnou degradaci výkonu.
Jádro SCSI cíle LIO bylo začleněno.
Řízení propustnosti blokového I/O může být nyní využíváno hierarchickými kontrolními skupinami.
Bloková vrstva má nyní mechanismus pro „zpracování událostí“. To znamená, že detekci událostí v těchto zařízeních (například vložení optického disku) mohou zajišťovat ovladače, což odbourává nutnost neustále se dotazovat z uživatelského prostoru.
dm-crypt device maperu má nyní režim „multikey“, který umožňuje zašifrovat různé bloky různými klíči. Cíl crypt nyní také umí přistupovat k zašifrovaným oddílům vytvořených balíkem loop-AES, který je mimo strom.
Device mapper získal možnost spravovat svazky RAID4/5/6 použitím ovladačů MD RAID.
Systémové volání clone() již nedodržuje dlouhodobě zastaralý příznak CLONE_STOPPED.
Souborový systém btrfs získal podporu pro snímky [snapshot] pouze pro čtení a LZO kompresi.
Mezi změny viditelné pro vývojáře patří:
Do adresáře tools byl přidán nástroj ktest.pl, který umožňuje automatizovat překládání, testování a dělení jader půlením.
Specifikátor formátu „%pK“ lze použít k vypisování hodnot potenciálně citlivých ukazatelů v jádře, obzvláště v místech, jako jsou soubory v /proc. Chování tohoto formátu závisí na hodnotě /proc/sys/kernel/kptr_restrict; hodnota nula znamená, že ukazatele budou vypisovány jako obvykle, zatímco jednička způsobí, že se uživatelům bez CAP_SYSLOG vypíše nula. Dvojka skryje ukazatele všem.
Byla odstraněna funkce cdev_index; vzhledem k tomu, že v jádře ji nikdo nepoužíval, pravděpodobně si toho nikdo nevšimne.
Nová funkce kref_test_and_get() vytvoří odkaz [reference] jenom v případě, že současný počet odkazů není nulový.
Byly přidány nějaké dentry operace, které podporují automatické připojování ve VFS.
Zpětné volání [callback] fallocate() bylo přesunuto z struct inode_operations do struct file_operations.
Seznam vlastnosti 2.6.38 je kompletní a proces stabilizace veškerého nového kódu může začít; konečné vydání 2.6.38 očekávejme někdy koncem března.
napsal Jonathan Corbet, 19 ledna 2011
Jednotka pro správu paměti téměř v každém dnešním procesoru dokáže pracovat s více velikostmi stránky, ale linuxové jádro se téměř vždy omezuje na nejmenší z těchto velikosti – na většině architektur 4096B. Stránky, které jsou větší než toto minimum – nazývají se velké stránky [huge pages] – mohou pro některé zátěže nabídnout větší výkonnost, ale na Linuxu se ani tak téměř nepoužívají. To by se v 2.6.38 mohlo se začleněním transparentních velkých stránek změnit.
Velké stránky mohou výkonnost vylepšit omezením počtu výpadků stránky [page fault] (jediný výpadek načte veký kus paměti naráz) a omezením nákladů na překlad virtuálních adres na fyzické (k získání fyzické adresy je potřeba projít méně úrovní tabulek stránek). Největší výhoda nicméně plyne z úplného odbourání tohoto překladu – když procesor musí přeložit virtuální adresu, musí projít celými čtyřmi úrovněmi tabulek stránek, u každé je šance, že nebude v cache a tudíž to bude pomalé. Z tohoto důvodu si procesory udržují buffer pro výsledky překladu [translation lookaside buffer, TLB], ve kterém se uchovávají výsledky překladů. TLB je často poměrně malý; cpuid na stárnoucím desktopu autora článku vrací:
cache and TLB information (2): 0xb1: instruction TLB: 2M/4M, 4-way, 4/8 entries 0xb0: instruction TLB: 4K, 4-way, 128 entries 0x05: data TLB: 4M pages, 4-way, 32 entries
Je zde tedy místo pro 128 překladů kvůli instrukcím a 32 kvůli datům. Tak malá cache se snadno zaplní, což nutí CPU provádět mnoho překladů. Jediná 2MB velká stránka vyžaduje jediný záznam v TLB; stejná paměť by v 4kB stránkách potřebovala 512 záznamů v TLB. Vzhledem k tomu není překvapením, že velké stránky mohou programům pomoci běžet rychleji.
Hlavní adresový prostor jádra je mapován velkými stránkami, což omezuje tlak na TLB ze strany jaderného kódu. Nicméně jediný způsob, jakým mohou aplikace v uživatelském prostoru využít velké stránky pod současnými jádry, je pomocí hugetlbfs, který byl rozsáhle popsán na LWN.net. Používání hugetlbfs vyžaduje značnou snahu jak ze strany vývojářů aplikací, tak systémových administrátorů; velké stránky se musí odložit stranou během bootu a aplikace je musí mapovat explicitně. Proces je tak náročný, že se používání hugetlbfs omezuje na ty, kteří opravdu chtějí a mají čas se s tím zabývat. Hugetlbfs se často považuje za vlastnost určenou pro velké proprietární databázové systémy a téměř nikoho jiného.
Mechanismus, který by zjednodušil používání velkých stránek pokud možno bez další práce vývojářů či administrátorů, by tedy byl velmi užitečný. Vytvořit takový mechanismus je přesně cílem patche transparentních velkých stránek [transparent huge pages, THP], který vytvořil Andrea Arcangeli a který byl začleněn do 2.6.38. V krátkosti se THP snaží zajistit, aby se velké stránky „prostě objevily“ v situacích, kdy budou užitečné.
Současná jádra předpokládají, že všechny stránky v jedné oblasti virtuální paměti [virtual memory area, VMA] budou stejně velké. Aby THP mohlo fungovat, musel se Andrea tohoto požadavku zbavit; většina počáteční části sady patchů se tedy věnuje tomu umožnit smíšené velikosti stránek ve VMA. Patch poté jednoduše modifikuje obsluhu výpadku stránky: když dojde k výpadku, jádro se pokusí alokovat velkou stránku. Pokud alokace uspěje, bude naplněna velká stránka, všechny existující malé stránky v adresovém rozsahu nové stránky budou uvolněny a velká stránka se vloží do VMA. Pokud nejsou žádné velké stránky k dispozici, jádro se vrátí zpět k používání malých stránek a aplikace si nikdy nevšimne rozdílu.
Toto schéma transparentně zvýší používání velkých stránek, ale to ještě problém neřeší. Velké stránky musí být možné odswapovat, kdyby systému rychle docházela paměť. Než aby komplikoval kód swapování tím, že do něj přidá podporu pro velké stránky, Andrea jednoduše rozdělí velkou stránku na malé. K rozdělení stránky vede i mnoho dalších operací (mprotect(), mlock(), ...)
Alokace velkých stránek závisí na dostupnosti velkých fyzicky spojitých kusů paměti – to je něco, s čím programátoři Linuxu nemohou nikdy počítat. Lze také předpokládat, že takové stránky budou najednou k dispozici až v době, kdy to k ničemu není – například když proces kvůli výpadkům nahrál do paměti mnoho malých stránek. THP se snaží tuto situaci vylepšit vytvořením jaderného vlákna „khugepaged“. Toto vlákno se občas pokusí alokovat velkou stránku; když uspěje, prohledá paměť a pokusí se najít místo, kde by touto velkou stránkou bylo možné nahradit hromadu menších stránek. Dostupné velké stránky by tedy měly rychle být využity, což maximalizuje jejich používání v systému jako celku.
Současný patch pracuje pouze s anonymními stránkami; k integraci velkých stránek do cache stránek ještě nedošlo. Také pracuje pouze s jednou velikostí stránky (2MB). I tak lze ale pozorovat užitečný nárůst výkonu. Mel Gorman zkusil pár benchmarků, které ukazují zlepšení v některých situacích až o 10 %. Obecně výsledky nebyly tak dobré v porovnání s tím, čeho lze dosáhnout pomocí hugetlbfs, ale u THP je mnohem pravděpodobnější, že se opravdu použije.
Kvůli využívání velkých stránek není potřeba nijak měnit aplikace, ale zainteresovaní vývojáři mohou zkusit optimalizovat jejich používání. Volání madvise() s příznakem MADV_HUGEPAGE označí kus paměti jako obzvláště vhodný pro velké stránky, zatímco MADV_NOHUGEPAGE naznačí, že velké stránky by bylo vhodnější použít jinde. Aplikace, které chtějí velké stránky používat, tomu mohou pomoci voláním posix_memalign() tak, že se velké alokace zarovnají na hranice velkých (2MB) stránek.
Správci systému mají mnoho knoflíků, kterými mohou používání velkých stránek ladit, všechny jsou k nalezení v /sys/kernel/mm/transparent_hugepage. Hodnota enabled může být nastavena na „always“ (vždy používat THP), „madvise“ (velké stránky používat pouze ve VME označených pomocí MADV_HUGEPAGE) či „never“ (THP vypnuto). Další knoflík defrag přijímá stejné hodnoty; řídí, jestli má jádro agresivně používat shlukování paměti a vytvářet tak více velkých stránek. Je zde také celá sada parametrů, které řídí fungování vlákna khugepaged; detaily vizte v Documentation/vm/transhuge.txt.
Patch THP měl od začlenění do hlavní řady trochu těžkou cestu. Kód se nikdy neobjevil v linux-next, takže překvapil některé správce architektur, protože kvůli němu selhával překlad. Také byly nalezeny nějaké chyby – žádné překvapení pro patch této velikosti, který navíc modifikuje velkou část základního kódu. Tyto problémy jsou postupně žehleny, takže i když by si testeři 2.6.38-rc1 měli dávat pozor, THP by mělo být ve finálním vydání jádra 2.6.38 použitelné.
Svobodný software strašně připomíná klobásy – úžasně chutné, ale někdy občas přijdete na to,...Jedno z nich tam je navíc...
Další knoflík defrag přijímá stejné hodnoty; řádí, jestli má jádro agresivně používat shlukování paměti a vytvářet tak více velkých stránek.
Nevím, jestli radí nebo řídí, ale je to kouzelný překlep…
31.1.2011 11:13
atan | skóre: 21
| Liberec
Seznam vlastnosti 2.6.38 je kompletní...Jak kompletní?? A co Dom0 backend ovládače? Zase nic? :(
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.