Portál AbcLinuxu, 5. května 2024 23:40
Aktuální verze jádra: 2.6.34. Citáty týdne: Linus Torvalds, Daniela Torvaldsová, James Bottomley, Matthew Garrett. Zápisky z jaderného minisummitu o chybách hardwaru. Rozšířené červeno-černé stromy. SLEB alokátor. Začleňovací okno 2.6.35, část první. Problémy s čítačem časových značek (TSC). Zablokované blokování uspání.
Není žádné vývojové jádro, protože začleňovací okno 2.6.35 je otevřené. V době psaní tohoto článku do hlavní řady proudí patche relativně pomalu; detaily vizte níže.
2.6.34 bylo vydáno 16. května. Jako obvykle je v tomto vydání spousta nových věcí, i když je o něco méně nabité novými vlastnostmi než jiná. Mezi nejvýznamnější patří asynchronní správa napájení, spousta vylepšení sledování, LogFS a distribuovaný souborový systém Ceph. Jako vždy lze spoustu detailů nalézt ve skvělém shrnutí na KernelNewbies.
V uplynulém týdnu nevyšly žádné stabilní aktualizace.
Několik vývojářů jádra se na Linux Foundation's Collaboration Summit zúčastnilo minisummitu věnovanému sběru a hlášení hardwarových chyb. Mauro Carvalho Chehab dal dohromady a zaslal nějaké poznámky z tohoto setkání; najdete je pod odkazem níže. Stojí za to poznamenat, že někteří vývojáři, kteří se nezúčastnili, zcela nesouhlasí se vším, co tam najdete; více informací naleznete v tomto diskuzním vlákně.
napsal Jonathan Corbet, 18. května 2010
Červeno-černé stromy (rbstromy) [red-black trees, rbtrees] jsou vysoce optimalizované datové struktury používané v jádře na mnoha místech. S rbstromem může programátor jádra rychle nalézt datové struktury odpovídající specifické hodnotě; stačí uložit tyto datové struktury s touto hodnotou jako klíčem. Složitější vyhledávání však může být s rbstromy složitější; jako příklad uvažme případ, kdy potřebujeme najít uzel s nejnižší hodnotou, která spadá do daného rozsahu hodnot. Venkatesh Pallipadi nedávno narazil na tento problém, když se pokoušel vylepšit podporu tabulek atributů stránek [page attribute table, PAT] u architektury x86. Místo toho, aby se na rbstromy vykašlal, se rozhodl tuto datovou strukturu vylepšit tak, aby vyhovovala širším potřebám.
Venkateshův patch (který byl jednou z prvních věcí začleněných do 2.6.35) implementuje koncept „rozšířených rbstromů“ [augmented rbtree]. Takový rbstrom funguje v podstatě jako běžný rbstrom s tou výjimkou, že v každém uzlu uchovává informace navíc. Tato informace je téměř s jistotou funkcí kteréhokoliv uzlu potomka [child node] ve stromě – například maximální hodnota klíče mezi všemi potomky. Vzhledem k tomu, že uživatelé rbstromů si musí vyhledávací funkci napsat sami, mohou tuto informaci navíc snadno využít a optimalizovat s její pomocí vyhledávání.
Uživatelé vylepšených rbstromů musí definovat zpětné volání [callback] augment_cb() s prototypem:
void (*augment_cb)(struct rb_node *node);
Když je strom inicializován, zpětné volání by mělo být uloženo v jeho kořenovém uzlu:
struct rb_root my_root = RB_AUGMENT_ROOT(my_augment_cb);
Poté bude zpětné volání augment_cb() spuštěno pokaždé, když se hodnota jednoho (nebo obou) uzlů potomka mohla změnit. Zpětné volání pak může aktualizovat doplňující informace uzlu, aby platily pro aktualizovanou topologii stromu. Bude voláno z operací vkládání a mazání – mohou strom měnit – takže uživatelé rbstromů by měli zajistit, aby před vložením uzlů byly tyto uzly v konzistentním stavu.
Zpětná volání se nevolají rekurzivně směrem ke kořenu stromu. Jestliže se tedy změna rozšířené hodnoty uzlu může projevit výše ve stromě, volání augment_cb() se musí ke kořenu propracovat a provést potřebné aktualizace. Rekurzivní volání u rodičovského uzlu není dobrý nápad, kromě případů, kdy víme, že je strom extrémně mělký.
V době psaní tohoto článku je kód PAT jediným uživatelem této funkce ve stromě, ale pravděpodobně se objeví další, když je teď tato vlastnost globálně k dispozici.
napsal Jonathan Corbet, 19. května 2010
Stálí čtenáři Jaderných novin ví, že jádro nemá jenom jeden vnitřní alokátor paměti. Máme zde starý „slab“ alokátor (který bude jednoho dne odstraněn), SLUB alokátor (měl mít lepší škálovatelnost, ale nepodařilo se mu porazit slab ve všech testech) a SLOB (efektivně pracující s místem, pro použití v embedded zařízeních). Také je zde alokátor SLQB, který čeká v povzdálí, ale čeká již tak dlouho, že je otázka, jestli se ještě někdy pohne.
Suma sumárum by se dalo říct, že alokátorů máme dost. Ale na druhou stranu v jmenném prostoru SL*B je ještě dost písmen, takže proč nevytvořit další?
Proto Christoph Lameter, autor alokátoru SLUB, přišel s alokátorem SLEB, jehož cílem je vzít to nejlepší ze slab a SLUB. Na rozdíl od SLUBu SLEB udržuje fronty objektů, které používá slab, ale také pro správu objektů přidává bitovou mapu. Další rozdíl oproti SLUBu je, že se v objektech samotných neukládají žádná metadata. To je výkonnostní zlepšení: Jestliže je alokován nebo uvolněn objekt se studenou cachí, SLEB ho do cache nenahraje.
Kód je velmi nový; pravděpodobně mu ještě nebylo svěřeno nic mimo virtuální stroj KVM. Dlouhý proces benchmarkování, který by mohl vést k začlenění a možná i k odstranění jednoho z ostatních alokátorů, ještě nezačal. Kód tu ale je a to je začátek.
napsal Jonathan Corbet, 19. května 2010
Je to tu zas: Začal nový vývojový cyklus jádra a v současnosti je otevřené začleňovací okno pro nový kód. V době psaní tohoto článku bylo do hlavní řady zařazeno nějakých 1100 neslučovacích sad změn. Nejvýznamnější změny viditelné pro uživatele jsou:
Subsystém sledování výkonnosti nyní podporuje režim „precizní na událostech založené vzorkování“ [precise event based sampling, PEBS] od Intelu, ve kterém hardware přímo nahrává informace o událostech do vyhrazené oblasti v paměti. Subsystém perf také nyní dokáže získat informace o výkonnosti ze starých procesorů Pentium 4.
Nástroj „perf kvm“, který umožňuje monitorování virtualizovaných hostů z hostitele, byl začleněn.
Kód dynamických sond má nyní lepší podporu pro mnoho základních celočíslených typů
Byly odstraněny konfigurační volby plánovače „fair sleepers“, „sync wakeups“ a „affine wakeup“. Zdá se, že vývojáři plánovače aktuálně mají za to, že bez těchto funkcí nebudou věci fungovat správně, takže jsou povoleny vždy.
Architektura SuperH má nyní podporu pro přidávání/odebírání CPU za chodu.
Nové ovladače:
Procesory a desky:
Různé: zařízení pro hodiny reálného času založené na DaVinci DM365
Mezi změny viditelné pro jaderné vývojáře patří:
Mechanismus „cpu_stop“ (dříve cpuhog) byl začleněn. cpu_stop umožňuje jádru nakrátko zabrat jeden nebo více procesorů.
Rozšířené rbstromy jsou nyní v hlavní řadě jádra.
Makro INIT_RCU_HEAD() odchází; pro fungování RCU nikdy nebylo zapotřebí a ladění RCU se přesouvá do infrastruktury pro ladění objektů.
Jak je vidět, začleňovací okno 2.6.35 začalo poměrně pomalu. Podle starého rozvrhu by mělo zůstat otevřené do konce měsíce; spekuluje se o tom, že ho Linus tentokrát uzavře o něco dříve, aby ztížil život správcům, kteří budou s požadavkem na přetažení čekat příliš dlouho. Tak jako tak zde příští týden najdete další seznam změn.
napsal Jake Edge, 19. května 2010
Čítač časových značek [time stamp counter, TSC] poskytovaný procesory x86 je čítač s vysokým rozlišením, který lze číst jedinou instrukcí (RDTSC), takže je lákavým cílem pro aplikace, které potřebují časové značky s jemným krokem. Bohužel je také poněkud nespolehlivý, takže jádro musí skákat skrz obruče, aby mohlo zjistit, jestli ho může použít, a zkusit detekovat, když je mimo. Snaha exportovat znalosti jádra o spolehlivosti TSC z mnoha důvodů narazila na silný odpor, přičemž největším z těchto důvodů je, že vývojáři jádra si nemyslí, že by vývojáři aplikací měli tento čítač používat přímo.
Dan Magenheimer a Venkatesh Pallipadi navrhli přidat adresář /sys/devices/tsc se záznamy odpovídajícími interním informacím jádra o TSC včetně příznaku tsc_unstable, který určuje, jestli jádro používá tento čítač jako stabilní zdroj hodin. Andi Kleen tento návrh zpochybnil:
K tomu přesně patch slouží, řekl Dan, protože aplikace nemají žádnou možnost, jak zjistit, jestli standardní systémové volání bude „rychlé“, nebo „pomalé“:
V závislosti na hardwaru mohou být gettimeofday() a clock_gettime() implementovány jako virtuální systémová volání a ne jako standardní systémová volání, což odbourává přechod z uživatelského prostoru do jádra. Tato volání jsou uložena ve zvláštní oblasti paměti v uživatelském prostoru (oblast vdso), ze které lze přistupovat k datům spravovaným jádrem, jako jsou tiky hodiny. Virtuální systémová volání jsou (relativně) rychlá, ale na některém hardwaru (nebo ve virtuálním stroji) jsou potřeba operace v jaderném prostoru, které přistupují ke spolehlivému čítači, takže tato volání nelze použít a volání těchto funkcí je pomalejší. Pro aplikace, které potřebují získávat desítky nebo stovky tisíc časových značek za sekundu, je rozdíl výrazný.
Dan ale věří, že pokud jádro zjistí, že TSC je pro jeho účely dostatečně stabilní, je tím garantováno, že je použitelný i pro aplikace. Arjan van de Ven a Thomas Gleixner ale rychle přišli s upozorněním: Arjan poznamenal, že stabilita TSC se může za určitých podmínek změnit, a pak by chyběl způsob, jak na to aplikace upozornit. Jeho rada: Přátelé nenechají své přátele použít v kódu aplikace rdtsc.
Thomas to, jak se může TSC rozjet, rozebral detailněji, zmínil přerušení správou systému [system management interrupt, SMI], která si s TSC hrají, aby se skryla, různá jádra mohou obsahovat různé hodnoty kvůli rozdílům při bootu a/nebo připojování za chodu, u více pouzder zase hrozí rozdíly kvůli samostatným hodinám nebo kvůli rozdílům ve frekvenci závislých na teplotě. U TSC zkrátka není spolehlivé nic: Tenhle pitomý hardware není spolehlivý, ať už má na sobě nálepku ,Tvrdím, že jsem spolehlivý‘, nebo ne.. Thomas nicméně navrhl možnou alternativu:
V současnosti existují nepojmenované „podnikové aplikace“, které se pokouší zjistit, jestli mohou TSC používat, a také to dělají, když si myslí, že ano – důvodem je nejistota panující ohledně výkonnosti gettimeofday() a spol. Dan navrhuje, že tuto informaci by bylo možné zpřístupnit:
Dan také položil otázku, jestli jaderní vývojáři netrpí syndromem „horkých kamen“, protože se v minulosti spálili, a teď odmítají o změnách jenom uvažovat. Thomas a Arjan ale oba upozornili, že neexistuje hardware, který by mohl poskytnout záruky, které Dan požaduje. A Thomas má i popáleniny, kterými to může prokázat:
I když diskuze obsahovala mnoho dalších zajímavých analogií, včetně provazů a nožů a kondomů vs. abstinence, neobjevila se (zatím) analogie s auty. Společná myšlenka je zjevně v tom, jestli by volání hodin měla být implementována jako virtuální systémová volání, nebo jestli je potřeba exportovat systémová volání. To pravděpodobně neuspokojí ty, kdo už nějakou chvíli používají vsyscally a stále je z výkonností bolí hlava, a které Dan citoval; není ale nic, co by aplikacím bránilo používat TSC přímo. Takové aplikace musí ale být připraveny na to vyrovnat se s podivným chováním TSC, když na něj narazí.
Ingo Molnár se pokouší objasnit důvody, proč jádro nechce exportovat žádné informace o spolehlivosti: Důvod je to, že jádro nehodlá spolupracovat na praktikách, které nejsou technicky spolehlivé […] Jádro tedy nebude ,signalizovat‘, že lze něco bezpečně použít, když to bezpečně použít nelze. Také ale vidí určitou naději:
Peter Zijlstra má další řešení problému. Byl by rád, kdyby jádro přikročilo k blokování RDTSC pro uživatelský prostor. Emulací instrukce a logováním jejího používání (a s ní spojené instrukce RDTSCP) by bylo možné najít a změnit programy v uživatelském prostoru:
Exportování informací o tom, jestli je gettimeofday() „pomalá“, nebo ne, vypadá jako rozumný počáteční bod. Žádné patche se ohledně toho ještě neobjevily, ale jedná se o poměrně přímočarou záležitost. Může se objevit i něco jako Thomasova vget_tsc_raw(), ale to neuspokojí ty, kteří nejsou spokojeni se současnou výkonností virtuálních systémových volání. Takové aplikace budou prostě muset číst TSC samy a poradit si se vším, co na ně hardware hodí.
napsal Jonathan Corbet, 18. května 2010
Když se Jaderné noviny v dubnu naposledy dívaly na blokování uspání [suspend blockers], vypadalo to, že tato funkce je na své cestě k brzkému začlenění do jádra. Na této cestě možná stále je, ale další diskuze obraz trochu zakalila. Jedná se o relativně malý a obskurní kus kódu, ale osud blokování uspání může mít významné dopady na to, jak se jaderná komunita v budoucnosti vypořádá s externími projekty.
Vzpomeňme, že blokování uspání je spojeno s „oportunistickým uspáváním“, které používá systém Android. V tomto režimu já jádro přepnuto do stavu řízené narkolepsie; usne (a uspí systém) téměř pokaždé, kdy s ním nikdo necloumá. Blokování uspání je způsob, jak s ním cloumat, jedná se o způsob, kterým lze systém udržet vzhůru, když probíhá zpracování něčeho důležitého. Dokud je blokování uspání aktivní, systém se neuspí.
Tento přístup má dva aspekty, které vývojářům Androidu vyhovují. Jeden je, že jsou takto schopni vytěžit lepší správu napájení (delší životnost na baterie) uspáním celého systému, když se nic neděje. Používání běžné správy napájení za běhu nepodává stejné výsledky. Další klíčový bod je, že k oportunistickému uspání může dojít, i když v uživatelském prostoru běží procesy. Pokud není uspání zablokováno, probíhající výpočet není považován za dostatečně důležitý, aby kvůli tomu systém zůstal vzhůru. Toto chování je obrana proti špatně napsaným aplikacím, které by jinak mohly rychle vybít baterie.
Blokování uspání má několik nadšených příznivců. Oportunistické uspávání vypadá trochu jako hack a potřeba vložit blokovače uspání do ovladačů vypadá invazivně – i když bude ve většině jader tato funkce vypnutá, vypadá to jako břemeno pro údržbu. I tak se ale většina vývojářů, kteří se zapojili do diskuze – což zahrnuje téměř každého, kdo pracuje na správě napájení v Linuxu – shodla na tom, že lepší nápad nikdo nemá. Matthew Garret tedy řekl:
Alternativy byly v této diskuzi požadovány několikrát, ale skutečných návrhů bylo málo. Mnoho oponentů blokování uspání se spíše snažilo změnit požadavky – například stanovit povinnost, aby všechny aplikace pro Android byly napsané dobře. Problém je v tom, že když baterie nevydrží dostatečně dlouho, uživatelé to svedou na zařízení (a ne na úžasnou aplikaci, co funguje jako píšťalka na psa). Vývojáři Androidu si tedy musí vybrat mezi do určité míry vynuceným dobrým chováním (například zahozením „otevřeno pro všechny“, což je základní myšlena toho, jak se u Androidu věci dělají), nebo vytvořením dostatečně robustního systému, který bude fungovat i s neideálními aplikacemi.
Vývojáři Androidu zvolili druhý přístup. Přitom vytvořili blokování uspání, což je klíčová součást jejich platformy. Mnoho z ovladačů, které byly vyvinuty pro Android, má podporu pro blokování uspání zabudovanou; v současné podobě je nelze začlenit, když nebudou mít k dispozici API pro blokování uspání. V současnosti je tedy možné buď ovladače držet mimo, nebo z nich vyhackovat blokování uspání a začlenit je bez něj. V prvním případě budeme mít víc kódu mimo strom, v tom druhém budeme mít ve stromě ovladače, které se nepoužívají, netestují a neudržují. Ani jedna z těchto možností není dobrá.
Začlenění blokování uspání by značně zjednodušilo dostat do jádra zbytek kódu; vývojář Androidu Brian Swetland řekl:
(„Probouzecí zámky“ [wakelocks] je staré jméno pro blokování uspání.)
Google a vývojáři Androidu si užili spoustu starostí spojených s tím, že se jim nepodařilo pracovat s upstreamem a dostat kód do hlavní řady. Není pochyb, že kód bylo možné zvládnout lépe; kdyby vývojáři Androidu pracovali s jadernou komunitou dříve, než ho začali dodávat v miliónech zařízení, dalo by se možná většině potíží vyhnout. Historii ale teď přepsat nepůjde; to nedokáží ani tajné „instalatérské“ příkazy gitu. Můžeme ale zlepšit budoucí situaci.
Snaha spojená s blokováním uspání vypadá jako skutečný pokus pracovat lépe. Kód nebyl jenom zaslán; prošel více revizemi, než je obvyklé, jak se jeho vývojáři snažili reagovat na komentáře ostatních. Nezačlenit ho by bylo přinejmenším demoralizující. Jestliže vývojová komunita odmítne tento pokus přiblížit Android hlavní řadě, riskuje vznik špatného dojmu. Jestliže kód neakceptujeme, neměli bychom si stěžovat na to, že ho udržují mimo hlavní řadu.
V době psaní tohoto článku je začleňovací okno 2.6.35 otevřené. Co se stane s blokováním uspání, můžeme hádat. Vývojáři správy napájení jsou pro začlenění, ale jiní nadělali spoustu hluku a Linus ještě svoje názory najevo nedal. Těžko tedy říci, jestli se tento dlouhý příběh blíží ke svému konci, nebo ne.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.