Portál AbcLinuxu, 25. prosince 2025 14:23
Jaderné noviny – 17. 3. 2010
Články
-
Jaderné noviny – 17. 3. 2010
Aktuální verze jádra: 2.6.34-rc1. Citáty týdne: Frederic Weisbecker, Ingo Molnár, Eric Sandeen. Po zavření začleňovacího okna… Velké čtenářské zámky. Zabírání procesoru jádrem.
Obsah
Aktuální verze jádra: 2.6.34-rc1
link
Současné vývojové jádro je 2.6.34-rc1; během minulého týdne nebyly vydány žádné nové předverze.
Stabilní aktualizace: 15. března byla vydána jádra 2.6.32.10 a 2.6.33.1, se 145 a 123 patchi jsou obě obrovská.
Citáty týdne: Frederic Weisbecker, Ingo Molnár, Eric Sandeen
link
Možná bych si měl v celém bytě vylepit plakáty s fotkami modulů a nápisy „Chci věřit“. Nebo si možná koupím elektronické brýle, které budou na ulici zobrazovat reklamy na moduly. Ještě nevím, ale na něco přijdu.
-- Frederic Weisbecker
Myslel jsem si, že se všichni poučili ze selhání SystemTapu (a do určité míry to stálo i za selháním Oprofile): Když dojde na nástroje a osazování, nechceme se soustředit na úžasná složitá nastavení a abstraktní požadavky, které se vymyslel CIO, protože to k vývoji nikdo nepotřebuje. Koncentrujte se na dnešní vývojáře a poskytněte využitelné nástroje bez kompromisů těm, kteří něčím přispívají.
Jestliže nebude práce v nejjednodušším (a nejčastějším) případě pohodlná, tak jsme od základu selhali.
-- Ingo Molnár
Jan navrhuje, abychom nezaskočili uživatele tím, že bude ve výchozím nastavení povoleno delalloc, když je ext3 připojen pomocí ovladače ext4. Jenže jsou tu i další rozdíly v chování, přinejmenším mě napadá mballoc. A co omezení na 32000 podadresářů? Když přejdeme zpět na ext3, vyrovná se s časovými značkami s rozlišením na méně než sekundy a časy vytvoření? Možná… testovali jsme něco takového?
Kdy se dostaneme do bodu, kdy budeme při popisování ext4.ko zvažovat, jestli má cenu zabývat se fázemi měsíce?
-- Eric Sandeen
Po zavření začleňovacího okna…
link
napsal Jonathan Corbet, 16. března 2010
Na konci vývojového cyklu 2.6.33 Linus naznačil, že příští začleňovací okno bude o něco kratší než obvykle. A 2.6.34-rc1 opravdu vyšlo 8. března, dvanáct dní po vydání 2.6.33. Mnoho stromů zůstalo kvůli této změně na mraze a zdá se, že to Linusovi vyhovuje.
I tak byly některé stromy přetaženy po vydání -rc1. Mezi ně patří strom trivial s obvyklým nákladem oprav pravopisu a dalšími malými změnami. Také se objevila velká sada změn v ARM, včetně podpory pro mnoho nových desek a zařízení. Řadič využívání paměti získal novou vlastnost pro práh [threshold], což umožňuje jemnější řízení a získávání informací o využívání paměti. A tak dál, celkem bylo (v době psaní tohoto článku) od vydání 2.6.34-rc1 začleněno 1000 změn.
Když se ale objevil poslední požadavek na přetažení SCSI, Linus v ten okamžik nakreslil čáru do písku. Linuse, jak se zdá, trochu unavuje to, co u některých správců subsystémů považuje za jednání na poslední chvíli.
Už jsem to říkal dřív. Začleňovací okno je k začleňování, ne k vývoji. Když mi něco pošlete poslední den, tak tam není žádné „okno“. A je opravdu otravné mít poslední den padesát požadavků na přetažení [pull]. To už nehodlám dál snášet.
Linus tedy říká, že má v plánu být v budoucnu ještě méně předvídatelný. Determinismus v této fázi vývojového procesu evidentně vede k chování, které nemá rád, takže v budoucnu vývojáři nebudou schopni říci, jak dlouhé začleňovací okno bude. V takovém prostředí většina správců subsystémů bude pracovat tak, jako by začleňovací okno bylo zkráceno na jediný týden – což byl nápad, který byl diskutován a odmítnut na Jaderném summitu 2009.
Velké čtenářské zámky
link
napsal Jonathan Corbet, 16. března 2010
Na patchích škálovatelnosti VFS Nick Piggin už pracuje nějaký ten pátek – což je pro nízkoúrovňovou práci zaměřenou na výkon běžné. Nedávno Nick začal patch dělit na menší části, přičemž každá z nich řeší jednu část problému a každou z nich lze zvažovat samostatně. Jeden z těchto kousků zavádí zajímavý mechanismus pro vzájemné vyloučení nazvaný velký čtenářský zámek [big reader lock] či „brzámek“ [brlock].
Těm, kteří si patch přečtou, budiž odpuštěno, když nebudou chápat, o co jde; cokoliv, co kombinuje záludné zamykání a třicetiřádková makra pro preprocessor, způsobuje vrásky na čele. Základní koncept je ale jednoduchý: Brzámek se snaží zajistit, aby zamykání pouze pro čtení bylo tak rychlé, jak to jenom jde, tak, že vytvoří pole spinlocků, pro každé CPU jeden. Kdykoliv CPU potřebuje získat zámek pouze pro čtení, zabere vlastní zámek. Zamykání pro čtení je tedy lokální pro CPU a neobjevuje se žádné odrážení řádku cache [cache line bouncing]. A vzhledem k tomu, že soupeření o spinlock specifický pro CPU by ve skutečnosti mělo být nulové, tento zámek bude rychlý.
Život je o trochu ošklivější, když je potřeba získat zámek pro přístup pro zápis. Ve zkratce: Nešťastné CPU musí projít celé pole a získat spinlock všech CPU. Na 64procesorovém systému je tedy potřeba získat 64 zámků. To rychlé nebude ani v případě, že se o žádný zámek nebude soupeřit. Tento typ zámku by se tedy měl používat zřídka a jenom v případech, kdy téměř zcela převažuje přístup pro čtení.
Jeden takový případ – cíl tohoto zámku – je vfsmount_lock, který je vyžadován (pro čtení) při vyhledávání cest [pathname lookup]. Tato vyhledávání jsou častá a zjevně kritická pro výkonnost. Na druhou stranu je přístup pro zápis potřeba pouze v případě, kdy se připojuje nebo odpojuje souborový systém – což se děje mnohem méně často. Brzámek se sem tedy velmi dobře hodí a jeden (z mnoha) malých kousků puzzle škálovatelnosti VFS je na místě.
Zabírání procesoru jádrem
link
napsal Jonathan Corbet, 16. března 2010
Mezi běžná pravidla jádra patří to, že se snaží vyhnout spotřebování většího množství zdrojů, než je nezbytně nutné; systémový čas je lépe využíván programy v uživatelském prostoru. Patch pro zabrání CPU Tejuna Heo je tedy možná trochu překvapující; vytváří mechanismus, kterým si jádro může vyhradit monopol na jedno či více CPU a spustit na něm nicnedělající proces o vysoké prioritě. Tato sada patchů má ale dobré odůvodnění; a dokonce může v některých situacích vylepšit výkonnost.
Předpokládejme, že chceme zabrat jedno nebo více CPU v systému. První krok je vytvoření zabírací [hogging] funkce:
#include <linux/cpuhog.h>
typedef int (*cpuhog_fn_t)(void *arg);
Když přijde čas na zabírání, je tato funkce zavolána s nejvyšší možnou prioritou. Jestliže je cílem opravdu CPU zabrat, tato funkce by pravděpodobně měla běžet v těsné smyčce. Je ale potřeba zajistit, aby tato smyčka mohla někdy skončit; nikdo pravděpodobně nebude chtít vyřadit CPU navždy.
Zabrání procesoru se provádí jednou z funkcí:
int hog_one_cpu(unsigned int cpu, cpuhog_fn_t fn, void *arg);
void hog_one_cpu_nowait(unsigned int cpu, cpuhog_fn_t fn, void *arg,
struct cpuhog_work *work_buf);
int hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg);
int try_hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg);
Volání hog_one_cpu() způsobí, že se daná fn() spustí na cpu v režimu kompletního zabrání; volající proces bude čekat, než se fn() vrátí; v tu chvíli je předána návratová hodnota fn(). Pokud je potřeba zároveň s tím dělat nějakou užitečnou práci (na jiném CPU), je potřeba použít hog_one_cpu_nowait(); vrátí se okamžitě, přičemž fn() může v tom okamžiku ještě běžet. Strukturu work_buf musí alokovat volající a nepoužívat ji, o víc se ale volající starat nemusí.
Někdy není úplná kontrola nad jedním CPU dostačující; v takovém případě lze volat hog_cpus(), která spustí fn() naráz na všech CPU stanovených cpumask. Varianta try_hog_cpus() je podobná, ale na rozdíl od hog_cpus() nečeká, pokud někdo zabral CPU před ní.
K čemu by tento mechanismus tedy mohl být? Jedna možnost je stop_machine(), která se volá, aby se zajistilo, že se v systému chvíli nebude vůbec nic dít. stop_machine() se obvykle volá, když v systému probíhají zásadní změny – například jsou vkládány dynamické sondy, nahrávány jaderné moduly nebo odstraňována CPU. To vždy fungovalo stejným způsobem jako funkce pro zabrání CPU – spuštěním vlákna o vysoké prioritě na každém procesoru.
Nová implementace stop_machine() přirozeně používá hog_cpus(). Na rozdíl od předchozí implementace (která využívala pracovní fronty) nový kód využívá vlákna pro zabírání CPU, která již existují. To odstraňuje výkonnostní bug, který nahlásil Dimitri Sivanich, kde je množství času potřebného pro boot systému zdvojnásobeno kvůli režii různých volání stop_machine().
Další využití je vynucení toho, aby každé CPU rychle prošlo plánovačem; to může být užitečné, pokud chce systém vynutit přechod do nového ochranného období [grace period] při čtení-kopírování-zápisu. Dříve byla tato úloha poněkud podivným způsobem zabudována do vlákna migration, které již nyní běží na každém CPU jedno; nyní se používá přímočaré volání pro zabrání CPU.
Vlákno migration je samo o sobě také uživatelem funkce pro zabrání jednoho CPU. Toto vlákno přichází ke slovu, když chce systém přestěhovat proces běžící na daném CPU. První věc, kterou je potřeba udělat, je vysídlit tento proces z CPU – úkol, pro který se zabírání CPU dobře hodí. Jakmile zabírací funkce CPU převezme, právě vystěhovaný proces lze přestěhovat do nového domova.
Konečným výsledkem je odstranění slušného množství kódu, pročištění implementace vlákna migration a zlepšení výkonnosti stop_machine(). Objevily se obavy, že pokud by jako zabírající funkce byla předána funkce, která blokuje, mohlo by to v některých situacích způsobit problémy. Blokování při zabírání CPU se ale zdá být z principu kontradikce; lze očekávat, že obvyklá reakce bude „to nedělej“. A druhá verze patche dokonce zakazuje v zabíracích funkcích spát. Reakce „to nedělej“ bude samozřejmě i odpověď na většinu použití zabírání CPU obecně; zabírání procesorů v jádře je stále ve většině případů považováno za nespolečenské.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
20.4.2010 09:26
Thunder.m | skóre: 35
| blog:
e17
Re: Jaderné noviny – 17. 3. 2010
20.4.2010 12:41
jos
Re: Jaderné noviny – 17. 3. 2010
20.4.2010 15:16
Bedňa | skóre: 34
| blog:
Žumpa
| Horňany
Re: Jaderné noviny – 17. 3. 2010
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
20.4.2010 10:38
Nevidel by jste rozdeleni partici. Leda ze by se radic prepl do no-raid modu, a nabizel by vam disky naprimo, ale zde by opet nebyl zadny viditelny oddil, pouze veeeelky disk.
Hodte sem dmesg z beziciho jadra, a pak config z Vaseho noveho. Takto by jsme mohli zvazovat moznosti do nekonecna 
20.4.2010 15:16
