Jaderné noviny - 10. 12. 2008

20. 1. 2009 | Jirka Bourek | Jaderné noviny | 3564×

Aktuální jádro: 2.6.28-rc8. Citáty týdne - všechny o dokumentaci. Nový realtimový strom. Vysledování "smyčky na útěku". Souboj monitorů výkonnosti.

Obsah

• Aktuální jádro: 2.6.28-rc8
• Citáty týdne - všechny o dokumentaci
• Nový realtimový strom
• Vysledování "smyčky na útěku"
• Souboj monitorů výkonnosti

Aktuální jádro: 2.6.28-rc8

Současné vývojové jádro je 2.6.28-rc8 vydané 10. prosince. 2.6.28-rc8 obsahuje další dlouhý seznam oprav, včetně některých pro poměrně důležité regrese.

Linus také poznamenává (v oznámení 2.6.28-rc8), že řeší otázku, zda vydat 2.6.28 před svátky nebo až po nich. Žádá o návrhy, kterých, jak lze očekávat, dostane spoustu.

Současné stabilní jádro 2.6 je 2.6.27.8 vydané 5. prosince. Jde o rozsáhlou aktualizaci s opravami široké škály problémů.

Citáty týdne - všechny o dokumentaci

Z nějakého důvodu vypíná psaní jaderné dokumentace [kerneldoc] lidem mozek. Možná je to protože "hm, teď se ode mě očekává, že sem napíšu nějakou dokumentaci" místo "jů, tenhle kód vypadá nejasně, ten musím ozřejmit".

-- Andrew Morton

Osobně kerneldoc vůbec nemám rád, protože pravda je ta, že lidé budou radši pracovat na opravování chyb a dalších užitečných věcech místo toho, aby udržovali kerneldoc aktuální. A to je základní fakt, který nelze popřít.

Přál bych si, aby to fungovalo, ale nevidím jak. Takže pokud k tomu nebudeme mít vycvičené opice, které budou procházet všechny patche, jež jdou do stromu, a příslušně kerneldoc aktualizovat, bude kerneldoc chronicky někde špatně.

To vede ke zmatení a ztracenému času vývojářů, protože pokud jsou kousky kerneldoc chybné, je k ničemu.

-- David Miller

Očekával bych: neuvidíte, že bych těžce časem slovo vytvářející větu smysluplnou. Nikdy.

-- Rusty Russel

Jako vždycky: Nikdy byste neměli spoléhat na komentáře kódu, ty vás akorát zmatou.

-- Manfred Spraul

Nový realtimový strom

Nyní to bude něco přes čtyři roky od doby, kdy diskuze o reálném čase (realtime) zvážněla a vznikla sada patchů realtime preempce. Během této doby bylo možné slyšet mnoho předpovědí o tom, kdy bude jádro práce na realtime začleněno; obvykle byl odhad "přibližně během roku". I když mnoho z práce na realtime bylo začleněno, některé z klíčových komponent realtime stromu zůstávají mimo hlavní řadu jádra. Kromě toho realtimoví vývojáři byli během tohoto roku relativně potichu - alespoň co se realtime týče. Vzhledem k tomu, že se ujali nějakých malých vedlejších úkolů - jako je unifikace architektury x86 a zajištění jejího pokroku například - byli tito vývojáři v nedávné době trochu zaneprázdněni.

Realtime patch nicméně nezmizel. Když nic jiného, tak fakt, že mnoho distributorů daný kód dodává, je dostatečný k tomu, aby se zajistil zájem o jeho vývoj. Proto si autor tohoto článku se zájmem všiml nedávného oznámení nového -rt stromu s aktualizovanou sadou realtime patchů. Tento strom bude zajímat každého, kdo se bude chtít podívat na práci na realtime v kontextu jádra 2.6.28 a novějších.

Jednou z klíčových technologií realtimového stromu je změna způsobu, jakým fungují spinlocky. Spinlocky v hlavní řadě znamenají aktivní čekání do doby, než je požadovaný zámek k dispozici; pokud je snaha získat zámek, o který se soupeří, procesor je tak bez užitku zaneprázdněn. Držení spinlocku zabrání v tom, aby bylo vlákno odstraněno preempcí. Toto chování je obvykle nejlepší pro propustnost systému; také usnadňuje napsat správný kód. Nicméně cokoliv, co brání CPU okamžitě obsloužit proces s nejvyšší prioritou, jde proti hlavnímu návrhovému cíli realtimového operačního systému: poskytnout deterministický čas odezvy ve všech situacích. Takže, co se realtimových patchů týče, klasické spinlocky musí zmizet.

Řešením bylo změnit většinu spinlocků do podoby mutexu s děděním priority. Proces, který se pokusí získat "spinlock", o který se soupeří, již neskončí v nekonečné smyčce; místo toho se uspí a čeká, než se zámek uvolní, takže je procesor k dispozici jinému vláknu. Kód, který drží některý z těchto ne-spinlocků, již není imunní vůči preempci; proces s vyšší prioritou ho vždy může vytlačit z cesty. Změnou spinlocků tímto způsobem byli realtime vývojáři schopni odstranit jeden z největších zdrojů latence v jádře hlavní řady. Mnoho z této práce si svou cestu do hlavní řady před časem našlo ve formě API mutexů, ale spinlocky samy o sobě v hlavní řadě změněny nebyly.

Aby minimalizovali problémy s údržbou realtime patchů, vývojáři prostě předefinovali typ spinlock_t, aby to byl nový typ mutexu. S výjimkou, že, jak se ukazuje, některé spinlocky v nízkoúrovňových částech jádra musí stále být spinlocky. Tyto tedy byly změněny na nový typ raw_spinlock_t - ale bez změny různých volání spin_lock. Místo toho bylo zavedeno opravdu děsivé čarování s makry, které způsobí, že API spinlocků udělá správnou věc, když je mu předáno kterékoliv z těchto dvou zcela odlišných primitiv pro vzájemné vyloučení [mutual exclusion]. Takováto magie s makry bylo vždy překážkou pro začlenění do hlavní řady, takže vývojáři realtime nikdy skutečně neočekávali, že bude zamykací kód v této podobě začleněn.

Nový realtime strom nyní ukazuje, jak si vývojáři myslí, že by se tato práce mohla dostat do hlavní řady. Zahrnuje to explicitnější oddělení těchto dvou typů "spinlocků" - a spoustu převracení kódu. V realtimovém stromě je většina zámků typu spinlock_t změněna na nový typ lock_t. Pro tento typ je nová sada operací:

#include <linux/lock.h>

lock_t zamek;

acquire_lock(&zamek);
release_lock(&zamek);

Pro normální ne-realtimový překlad jádra bude lock_t totéž jako spinlock_t a věci budou fungovat tak, jak fungovaly vždycky. V realtimových jádrech bude lock_t mutexový typ. Ostatní varianty API spinlocků jsou v novém API přítomny (je zde například acquire_lock_irqsave()), ale v realtimovém jádře žádná z nich ve skutečnosti nezakáže přerušení. Typ spinlock_t zůstane původním typem spinlocku.

Tato změna se zbavuje pochybných maker, ale za cenu změny deklarace a fungování téměř všech spinlocků v jádře. To znamená mnoho změn kódu: rychlý grep v přicházejícím jádře 2.6.28 ukazuje přes 20 000 volání spin_lock*(). To bude znamenat problémy, až a jestli bude tato změna začleněna. Mezitím ale bude způsobovat hodně problémů lidem, kteří budou chtít udržovat tento patch mimo strom. Aby jejich životy trochu ulehčili, vytvořili vývojáři realtime pár skriptů, které udělají většinu práce. V čistém jádře jsou nejprve všechny spinlocky změněny na lock_t, pak je těch pár zámků, které opravdu musí být spinlocky, změněno zpět. Tato práce je udržována v oddělené větvi, která se regeneruje podle potřeby; tímto způsobem se vývojáři realtime vyhýbají nutnosti provádět ošklivá začlenění, aby se drželi současných jader.

Autor článku se doslechl o další změně zamykání, která se - ještě - v tomto stromě neobjevila. Jedním problémem realtimové sady patchů je to, že od distributorů vyžaduje vytvořit zase další obraz jádra - což je něco, co dělají neradi - pokud chtějí podporovat fungování v reálném čase. Ve snaze zjednodušit distributorům život realtime vývojáři pracují na schématu, kde by jádro samo v době běhu určilo, jestli má běžet v režimu reálného času. Pokud ano, spinlocky by se změnily na spící zámky patchováním binárního obrazu jádra při bootování. Jádra přeložená tímto způsobem by byla schopná běžet efektivně v obou režimech.

Větve realtime stromu poskytují rychlý přehled o další práci na běhu v reálném čase, která zůstává mimo hlavní řadu. Jedním příkladem je kód obsluhy přerušení ve vláknech; tato změna by mohla být (opět) navržena k začlenění v blízké budoucnosti. Mechanismus priority pracovní fronty sedí v další větvi, stejně jako patche zaměřené na podporu Javy, změny v souborových systémech, změny ve správě paměti a další. Potom jsou zde větve pro záležitosti, které nebudou začleněny nikdy; například je tu tento patch, který dává programům v Javě přímý přístup k fyzické paměti - to většině jaderných vývojářů jako dobrý nápad nepřijde. Ve shrnutí: v sadě realtime patchů leží velký kus práce; tato práce je konečně organizována do korektního gitového stromu.

Politika "nejprve do upstreamu" říká, že prodejci by svůj kód měli začlenit do upstreamu předtím, než ho dodají zákazníkům. Vývojový model 2.6.x je založen na myšlence, že žádný nápad není tak zásadní, aby byl přijat v obvyklém tříměsíčním vývojovém cyklu. Realtimové patche se zdají být výjimkou v obou pravidlech: trvalo přes čtyři roky dostat je do stavu, kde jsou některé nejzákladnější technologie připraveny k začlenění, ale distributoři je dodávají již nejméně tři z těchto let. Jinými slovy jde o jeden z největších forků linuxového jádra v historii. Plán byl vždy takový, že tento fork bude připojen zpět k hlavní řadě jádra; možná - konečně - se blížíme k tomuto cíli. Při troše štěstí k tomu dojde přibližně během roku.

Vysledování "smyčky na útěku"

Proces bootování Linuxu, přinejmenším v té podobě, jakou poskytují distribuce, závisí na pomoci z uživatelského prostoru, kde se ovladače nahrávají podle potřeby z počátečního souborového systému (initramfs/initrd). Načtení ovladačů vyžaduje použití nástrojů zabudovaných do initramfs a když tyto nástroje selžou, jádro nenabootuje. Nicméně, když je funkční jaderná konfigurace a initramfs použito s novým jádrem, očekávaným výsledkem je, že jádro úspěšně nabootuje. Když se tak nestane, jsou oznamovány chyby ohledně jaderných regresí, ale jak ukazuje nedávný případ, skutečný problém může být jinde.

Původní hlášení vzniklo koncem října, ale nedošlo k žádnému pokroku, dokud ho Jevgenij Pojlakov neviděl znovu začátkem prosince. Symptomem bylo, že se jádro zaseklo po čtyřnásobném vypsání:

request_module: runaway loop modprobe char-major-5-1

do konzole. Vzhledem k tomu, že se v uživatelském prostoru (initramfs) ani v jaderné konfiguraci nic nezměnilo, zdálo se, že to jasně ukazuje někam do jádra.

Ukazuje se, že zpráva "runaway loop" má oznámit, že funkce request_module() byla vyvolána rekurzivně. Jinak řečeno, že ve snaze nahrát ovladač pro znakové zařízení s velkým/malým číslem 5/1 - což odpovídá /dev/console - byla funkce request_module() zavolána znovu. Kód v kernel/kmod.c

if (atomic_read(&kmod_concurrent) > max_modprobes) {
        /* We may be blaming an innocent here, but unlikely */
        if (kmod_loop_msg++ < 5)
                printk(KERN_ERR
                       "request_module: runaway loop modprobe %s\n",
                       module_name);
                atomic_dec(&kmod_concurrent);
                return -ENOMEM;
}

umožňuje vypsat tuto zprávu pouze čtyřikrát, ale volající by měl rozpoznat ENOMEM a odpovídajícím způsobem zareagovat.

Příčinou je, že něco v jádře se pokouší přistoupit k /dev/console předtím, než je zařízení registrováno v jádře. To vede jádro k tomu, že se pokusí nahrát modul, který obsluhuje /dev/console, což selže. Kvůli selhání se něco v uživatelském prostoru - modprobe - pokusí přistoupit k /dev/console, pravděpodobně aby se vypsalo chybové hlášení, což zopakuje proces nahrání modulu v jádře a tak dál. Jakmile je rekurzí dost na to, aby byl překročen limit max_modprobes, request_module() vypíše hlášení o smyčce a vrátí ENOMEM, což by celý proces mělo ukončit.

V zatrpklém vlákně - a jaderném hlášení chyby - se Alan Cox, Kay Sievers a Jevgenij pokusili přijít na to, kde problém vznikl a co s ním udělat. Záležitosti vůbec nepomohlo, že používali initramfs z různých distribucí, takže každý pozoroval jiné chování. Jevgenij a Kay používali uživatelský prostor Debianu, kdežto Alan Fedoru. Něco v debianní verzi se stále pokoušelo otevřít /dev/console i poté, co obdrželo ENOMEM. To vede k nekonečné smyčce a tím k zatuhnutí jádra.

Kay chybu nakonec vysledoval v jaderném kryptografickém API:

Je to způsobeno "modprobe cryptomgr" volaného ze swapper[1]

Tento pokus o nahrání modulu se snaží ohlásit chybu, přistoupí k /dev/console, které ještě jádro v danou chvíli neinicializovalo, a zavaděč jaderných modulů se pokusí nahrát modul podporující dev_t 5:1, což znovu spustí modprobe a ...

Nastavení CONFIG_CRYPTO_MANAGER=y to odstraní.

Ukazuje se, že crypto vrstva se pokouší nahrát modul cryptomgr jako součást infrastruktury testování algoritmů. Když nahrání cryptomgr selže, kód registrace algoritmů může pokračovat bez něj. Je to volitelné, ale modprobe chce vypsat zprávu, když se mu ho nepodaří nahrát, což vede ke smyčce. Nicméně, jak upozornil Herber Xu, problém vůbec není specifický pro crypto:

Ani v jednom případě smyčka nezahrnuje žádnou komponentu crypto, takže si nemyslím, že změny v kryptografické vrstvě zajistí, že tenhle problém zmizí navždy, protože každý, kdo bude volat request_module dostatečně brzo, se do této smyčky dostane.

To je potenciální past, kterou by Kay a Jevgenij rádi odstranili. Obecně se od programů v uživatelském prostoru neočekává, že by se musely zabývat dostupností /dev/console - kromě případu, když jsou spuštěny z časné inicializace jádra. Alan ale upozorňuje na to, že pomocné programy v uživatelském prostoru se musí zabývat tím, aby se vyhnuly smyčkám, protože je více možných způsobů, jak by k nim mohlo dojít. Jako příklad upozorňuje, že pokud jsou unixové sockety (AF_UNIX) v modulu a syslog() je zavolán před načtením modulu, objeví se podobná smyčka.

Ve snaze udělat "krok zpět" z diskuze, která nikam nevedla, nabídl Ted Ts'o svou analýzu problému společně s návrhem, jak ho řešit:

Je zde debata o tom, jestli jde o nekonečnou smyčku, nebo jestli by měla být zachycena detektorem rekurze modprobe v kernel/kmod.c. Alan zkontroloval detektor rekurze a hlásí, že funguje správně; Jevgenij a Kay tvrdí, že se ve skutečnosti točí ve smyčce a že detektor rekurze nefunguje.

[...] Proto si myslím, že nejlepší, co můžeme udělat, je zjistit, co dělá debianní initrd, když se vyhne detekci rekurze. Když se to opraví, bude výsledek robustnější.

Detektor rekurzí zjevně v určitém rozsahu funguje, jinak by nebylo vidět hlášení o smyčce, ale minimálně na Debianu tato detekce problém neodvrátí. Tedova teorie je, že viníkem je něco mimo přímo volanou pomocnou aplikaci: Hádám, že důvod, proč to nefunguje s debianním nastavením initrd, je v tom, že to, co nakonec otevírá /dev/console, není voláno do doby, dokud se pomocný skript neukončí. Zdá se, že by stálo za to to prozkoumat, jak Ted zdůrazňuje v pozdější zprávě:

Bylo by dobré se ujistit, že rozumíme tomu, jaká je prvotní příčina toho, že se detektor rekurze modprobe zjevně nespouští, protože to může být tak, že debianní initrd může způsobit nějakou jinou nezachycenou rekurzivní smyčku.

Přesná příčina problému a důvod, proč se Debian a Fedora chovají jinak, stále není znám. Prohledávání debianního initrd, aby se na to přišlo, jak Ted navrhuje, je zjevně správný počáteční bod. Odpověď na to pravděpodobně povede k rozumným opravám buď v uživatelském prostoru, nebo v jádře - možná v obou. Dohadování se o tom, kde je problém a jak ho opravit, předtím, než je plně pochopen, se zdá být přinejlepším kontraproduktivní.

Souboj monitorů výkonnosti

Nízkoúrovňové optimalizace kódu kritického pro výkonnost mohou být náročnou výzvou. V současnosti se dá předpokládat, že všechna potenciální algoritmická vylepšení kódu byla realizována; co zbývá, je pokusit se najít a vyřešit problémy, jako jsou přístup k datům, která nejsou v cache, špatně předpovězené skoky a tak dál. Takové problémy nemusí být možné najít pouhým pohledem na kód; je potřeba podpora hardwaru. Dobrá zpráva je, že současný hardware tuto podporu poskytuje; většina procesorů může sbírat široký rozsah dat spojených s výkonností k pozdější analýze. Špatná zpráva je, že procesory byly schopné tato data sbírat mnoho let, ale hlavní řada jádra pro tento druh sledování výkonu nikdy neobsahovala podporu. Tato situace se možná změní, ale nejprve si komunita vývojářů musí vybrat mezi věkovitou implementací mimo strom a jejím neočekávaným soupeřem.

Patch "perfmon" byl vyvíjen několik let, ale z několika důvodů si do hlavní řady jádra cestu nenašel. Nejnovější verzi patche zaslal k revizi Stéphane Eranian koncem listopadu. Na patchi jsou vidět všechna ta léta vývoje a používání; nabízí širokou sadu vlastností a rozsáhlou podporu v uživatelském prostoru. Kompletní patch perfmon přidává do jádra dvanáct systémových volání, zaslaná verze nicméně tento počet omezuje na pět s nadějí, že užší rozhraní bude mít větší šanci se do hlavní řady dostat. Dá se předpokládat, že ostatní systémová volání budou navržena k začlenění nějaký čas poté, co bude začleněno jádro perfmon. Zredukované rozhraní je popsáno v této sadě patchů; ve stručnosti se aplikace připojí k subsystému monitorování výkonnosti voláním:

int pfm_create(int flags, pfarg_sinfo_t *regs);

Toto volání vrátí popisovač souboru [file descriptor], který identifikuje sezení sledování výkonnosti. Parametr regs se používá k získání seznamu registrů sledování výkonnosti, které jsou na současném systému k dispozici; flags se v současnosti nepoužívá.

S konkrétními čítacími registry výkonnosti lze manipulovat funkcemi:

int pfm_write(int fd, int flags, int type, void *d, size_t sz);
int pfm_read(int fd, int flags, int type, void *d, size_t sz);

Tato systémová volání lze použít k zápisu hodnot do registrů (a tím naprogramování hardwaru sledování výkonnosti) a ke čtení čítačů a konfiguračních informací z těchto registrů.

Skutečné monitorování výkonů vyžaduje o pár volání víc:

int pfm_attach(int fd, int flags, int target);
int pfm_set_state(int fd, int flags, int state);

Volání pfm_attach() specifikuje, který proces má být monitorován; pfm_set_state() poté sledování vypíná a zapíná.

Rozhraní perfmon má několik výrazných aspektů. Jedním je to, že téměř nic neví o specifických registrech sledování výkonu; očekává se, že tato informace se nachází v uživatelském prostoru. Výsledkem je, že holá systémová volání perfmon nejsou něco, co by většina sledovacích aplikací chtěla používat; místo toho jsou tato systémová volání skryta v knihovně v uživatelském prostoru, která ví, jak naprogramovat různé typy procesorů tak, aby byly získány požadované výsledky. Kromě toho perfmon používá mechanismus ptrace(), aby sledovaný proces zastavil po dobu, kdy se čtou čítače spojené s výkonností; důsledkem je, že sledovací proces musí mít právo sledovat cílový proces.

4. prosince Thomas Gleixner a Ingo Molnár zaslali překvapivé oznámení nového subsystému měření výkonnosti. Oznámení říká:

Jsme si vědomi toho, že sada patchů perfmon3 byla nedávno zaslána do lkml. Naše sada patchů se pokouší dosáhnout podobného konečného cíle, ale se zcela odlišným (a věříme, že lepším :-) návrhem.

Není to poprvé, co se tito vývojáři z ničeho nic objevili s reimplementací subsystému někoho jiného; další příklady zahrnují plánovač CFS, časovače s vysokým rozlišením, dynamický tik a realtime preempci. Ve většině případů nový kód rychle vytlačil starší verzi - což je něco, co původní vývojáře ne vždy potěší - ale situace tentokrát nevypadá tak jasně.

Navržené rozhraní je mnohem jednodušší, přidává jediné systémové volání:

int perf_counter_open(u32 hw_event_type, u32 hw_event_period,
                      u32 record_type, pid_t pid, int cpu);

Toto volání vrátí popisovač souboru odpovídající jednomu hardwarovému čítači. Volání read() potom vrátí současnou hodnotu čítače. hw_event_period lze použít k blokování čtení, dokud čítač nepřekročí danou hodnotu, což například umožňuje ptát se na události v násobcích 1000. Parametr pid lze použít k zaměření na specifický proces a cpu může sledování omezit na konkrétní procesor.

Tato implementace má mít několik výhod, jednou z nich je jednoduchost systémového volání; je možné napsat velmi jednoduchou aplikaci, která bude provádět sledovací úlohy bez potřeby používat další knihovny. Druhá verze patche obsahuje příkladovou utilitu "kerneltop", která umí zobrazovat neustále aktualizované sledování událostí, které hardware umí monitorovat. Další výhodou je vyhnutí se ptrace(); to omezuje privilegia potřebná k monitorování procesu a nevyrušuje ho neustálým pozastavováním a spouštěním. Správa čítačů má být flexibilnější s možností sdílení čítačů mezi procesy a jejich rezervování pro administrativní přístup. Stejně tak má být jednodušší nízkoúrovňové rozhraní s hardwarem.

Bez ohledu na tyto předpokládané výhody se v souvislosti s tímto novým kódem pro monitorování výkonnosti objevily stížnosti. Na čelních příčkách seznamu se zdají být tyto dvě položky: API s jediným čítačem v jednom popisovači souboru a programování jednotky sledování výkonnosti hardwaru uvnitř jádra. Na straně API je největší obava z toho, že uložení každého čítače za jeho vlastní popisovač souboru ztěžuje korelaci dvou nebo více čítačů. Číst dva čítače znamená dvě nezávislá systémová volání read(); jako pokaždé v takovém případě se mezi těmito volání může stát prakticky cokoliv. Je tedy těžké říct, jaký vztah k sobě mají dvě různé hodnoty. Tato korelace je ovšem přesně to, co vývojáři snažící se o optimalizaci výkonnosti potřebují udělat. Paul Mackerras říká:

Vaše API má svou centrální abstrakci "čítače". Říkám, že tato abstrakce je špatná. Abstrakce opravdu musí být sada čítačů, které jsou všechny aktivní v přesně stejném intervalu, aby jejich hodnoty bylo možné smysluplně porovnat a určit jejich vztahy mezi sebou.

V odpovědi Ingo argumentuje, že ztráta přesnosti nezávislými systémovými voláními read() je malá - mnohem menší, než když jsou výsledky zatíženy chybou vzniklou zastavením cílového procesu, aby bylo možné přečíst čítače naráz. Tento argument nicméně, jak se zdá, kritiky neumlčel.

Další stížnost je, že přesunutí úkolu programovat čítače do jádra vyžaduje, aby jádro znalo zvláštnosti každého možného sledování výkonnosti, na které může narazit. Sledovací hardware sedí v centru většiny pro výkonnost kritických subsystémů CPU, takže mezi jeho hlavní návrhové parametry patří nenarušování fungování těchto systémů a přímočaré programovací rozhraní. Programování tohoto hardwaru tedy může být komplexní záležitost zahrnující rozměrné tabulky popisující to, jak se mohou různé operace navzájem ovlivňovat. Kód perfmon tyto tabulky udržuje v knihovně v uživatelském prostoru, ale alternativní implementace by to neumožnila. Opět citujeme Paula:

A nyní - tabulky v uživatelské části perfmon, libpfm, které popisují mapování abstraktních událostí na hodnoty, podle kterých se tyto události vybírají, a omezení toho, které události lze čítat zároveň, mají téměř 29 000 řádků kódu jenom pro 64bitové powerpc procesory IBM.

Vaše API nás odsuzuje k tomu, abychom tohle všechno dali do jádra včetně kódu, který tyto tabulky používá.

Paul (a další) tvrdí, že tyto informace - které mohou zabírat stovky kilobytů - je lepší držet v uživatelském prostoru.

Objevují se také nějaké námitky k tomu, že Stéphane o této práci nikdy neslyšel předtím, než byla zaslána k revizi. Musí to být šok po léta pracovat na subsystému a pak najít ve své mailové schránce návrh na jeho náhradu. Jak to říká David Miller:

A další část negativních reakcí je vyvolána tím, že tahle věc byla skrývána před tím chudákem, který pracuje na perfmon3. Abych byl upřímný, to bylo pěkně nefér. Mohl mít skvělé nápady, co se potřeb týče (dokonce i když je vám jeho přístup, jak tyto potřeby naplnit, úplně ukradený), a tím mohl pomoci vyhnout se hádkám z posledních dní.

V tuto chvíli tedy není úplně jasné, co se stane s monitorováním výkonu. Je nicméně možné, že důsledkem této diskuze bude zviditelnění monitorování výkonnosti, které bylo mnoho let bez pořádné podpory v jádře. Začlenění kteréhokoliv řešení - nebo možná kombinace obou - se zdá být zlepšením oproti tomu nemít vůbec žádnou podporu.

       

Komentáře

[ByCzech]

Nebylo by lepší překládat "major" a "minor" jako "hlavní" a "vedlejší" či něco podobného než "velký" a "malý"?

 

Jinak pěkný článek. Díky za něj.

[YYY]

Slova "major" a "minor" bych neprekladal vubec. Jsou to podle mne jiz zabehle terminy(alespon u verzovani).

[petr_p]

Zaběhlé? Jaderné noviny 172 (2. 7. 2002):

Máme hlavní a vedlejší [major a minor] čísla pro sokety a plníme jimi /dev?

[Jary]

Tak a je to tu znova. Podle mě hlavní/vedlejší mnohem lepší, než velké/malé. Protože když řeknu "malé číslo" náhodnému člověku, tak si pod tím nepředstaví číslo méně rozhodující, ale číslo prostě malé. jako třeba 0.001, nebo - 2^15.

[multi]

+1

[petr_p]

Nevíte, co to je „Infrastruktura testování algoritmů“ a k čemu to je dobré?

Používám IPsec, a tak mám zapnuto CONFIG_CRYPTO_AUTHENC (ale vypnuté CONFIG_CRYPTO_TEST) a jádro mě průběžně otravuje hláškou:

alg: No test for authenc(hmac(sha1),cbc(des3_ede)) (authenc(hmac(sha1-generic),cbc(des3_ede-generic)))

[geebranz]

Smart suggestion

storageshedspensacola.com