![[Graf]](http://lwn.net/images/conf/rtlws11/rtsummit-chart-sm.png)
Portál AbcLinuxu, 5. května 2025 18:49
Aktuální verze jádra: 2.6.32-rc1. Citáty týdne: Christoph Hellwig, Linus Torvalds. Začleňovací okno 2.6.32, část třetí. Obhajoba zpětného zápisu pro BDI. TRACE_EVENT_ABI. Minisummit preempce v reálném čase.
Současné vývojové jádro je 2.6.32-rc1, které Linus vydal 27. září. Linus se uklepl, když psal číslo verze do makefile, takže toto jádro si myslí, že je -rc2. Významné změny přidané na konci začleňovacího okna vizte v článku níže.
Současné stabilní jádro je 2.6.31.1 vydané (společně s 2.6.27.35 a 2.6.30.8) 24. září. Tyto aktualizace obsahují mnoho důležitých oprav, některé z nich jsou spojeny s bezpečností.
Začleňovací okno 2.6.32 se uzavřelo 27. září vydáním 2.6.32-rc1; toto začleňovací okno bylo trochu delší, aby se vynahradilo zpoždění způsobené setkáním LinuxCon a Konferencí Linuxových instalatérů [Linux Plumbers Conference]. Mezi změny začleněné od článku z minulého týdne patří:
Souborový systém 9p (Plan9) byl aktualizován, aby používal cachovací vrstvu FS-cache.
K hierarchiím kontrolních skupin lze nyní připojit jména.
Systémové volání fcntl() podporuje operace F_SETOWN_EX a F_GETOWN_EX. Od F_SETOWN a F_GETOWN se liší tím, že ve vícevláknové aplikaci směřují signály SIGIO do specifického vlákna.
Byl začleněn subsystém HWPOISON.
Do grafických čipsetů Intelu byla přidána podpora komprese framebufferu. Komprese omezuje množství práce spojené s řízením displeje, což údajně vede ke snížení spotřeby o 0,5 W. Do grafického ovladače Intel také přibyla sada sledovacích bodů.
Jsou nové ovladače pro:
Prototyp funkce proc_handler používaný při obsluze sysctl ztratil nepoužívaný argument struct file.
V začleňovacím okně 2.6.32 bylo nakonec začleněno 8472 neslučovacích sad změn.
Mezi citáty z minulého týdne byla stížnost Andrewa Mortona na to, že v 2.6.32 je nahrazen kód pro zpětný zápis [writeback]. Podle Andrewa byl přepracován velký kus kritického kódu, čímž byla dobře prověřená implementace nahrazena novým kódem bez dobrého ospravedlnění. To je stížnost, kterou je třeba brát vážně; nahrazení kódu zpětného zápisu má potenciál zanést pro specifické zátěže výkonnostní regrese. Nemělo by to být provedeno bez dobrého důvodu.
Chris Mason se pokusil toto ospravedlnění poskytnout kombinací výsledků benchmarků a vysvětlení. Benchmarky se zpětným zápisem jednotlivě podle BDI ukazují zjevné – a velké – zvýšení výkonnosti; Andrew naznačil, že starší kód byl pomalejší v důsledku výkonnostních regresí zavedených postupem času jinými změnami. Pokud lze kód v 2.6.31 opravit, zlepšení výkonnosti lze (znovu)získat bez nahrazování celého subsystému.
Chris nicméně říká, že stará metoda jednoho pdflush pro CPU opravena být nemůže. Základní problém pdflush je ten, že ustoupí, pokud se zdá, že je zařízení přetíženo. Způsobit přetížení je ale jednoduché a žádná jiná část systému tímto způsobem neustoupí. Pdflush se tedy nakonec ke zpětnému zápisu nemusí dostat poměrně dlouhou dobu. Vynutit, aby všichni zapisovatelé v případě přetížení ustoupili, by sice věci vylepšit mohlo, ale byla by to velká změna, která neřeší jiný problém: Ústup z důvodu přetížení může znemožnit pokusy kódu souborového systému a blokové vrstvy zapsat velké a spojité segmenty na disk.
Jak se stává, do blokové vrstvy je již zabudován jiný a obecnější omezující mechanismus: Omezený počet probíhajících požadavků pro každé zařízení. Jakmile jsou požadavky vyčerpány, vlákna generující blokové I/O operace musí čekat, dokud se některé požadavky znovu neuvolní. Pdflush nicméně tento mechanismus použít nemůže, protože musí zpětný zápis provádět na několika zařízeních naráz; nemůže při alokaci požadavku blokovat. Vlákno pro zpětný zápis, které je specifické pro zařízení, může blokovat, protože to neovlivní I/O s jiným zařízením. Patch pro zápisy specifické pro BDI vytváří taková vlákna a výsledkem je, že je schopen zařízení vytížit lépe. To je, zdá se, důvod, proč starý kód bylo potřeba nahradit, a ne opravit.
Sledovací body se prokazují jako čím dál tím více užitečné nástroje pro vývoj systému a diagnostiku. Ohledně sledovacích bodů je nicméně jedna otázka, na kterou ještě neexistuje skutečná odpověď: Jsou sledovací body ABI pro uživatelský prostor? Pokud ano, do hry přicházejí vážná omezení. Jakmile je jednou ABI zpřístupněno, nesmí být změněno takovým způsobem, který by rozbil existující aplikace. Vzhledem k tomu, že jsou sledovací body pevně svázány s jaderným kódem, se kterým pracují, je přirozeně těžké je udržovat stabilní. A jestliže sledovací bod není možné změnit nebo odstranit, ztěžuje se tím změna kódu okolo něj. V nejhorším případě by nutnost dodržovat ABI mohla zablokovat důležité změny jádra – což je důsledek, který by mohl vývojářům myšlenku sledovacích bodů jako celku rychle otrávit.
Patch TRACE_EVENT_ABI Arjana van de Vena je pokus situaci trochu vyjasnit. Prozatím definuje sledovací bod stejně jako TRACE_EVENT; rozdíl je, že na takový bod by mělo být možné se spolehnout jako na součást jaderného ABI; měl by existovat i v budoucích vydáních jádra a formát spojený se sledovanou informací by se neměl změnit způsobem, který rozbije aplikace. V praxi to znamená, že by nebylo možné smazat žádné pole a nová pole by se přidávala na konec.
Jestli tento přístup bude fungovat, se ještě uvidí. Linus v minulosti říkal, že ABI vznikne tak, že se objeví aplikace, které závisí na nějakém rozhraní, nikoliv specifickém označením rozhraní jako takového. Jestliže tedy lidé začnou používat aplikace, které očekávají, že budou schopny využít specifický sledovací bod, pak tento sledovací bod může být zabudován do cementu bez ohledu na to, jestli byl definován s TRACE_EVENT_ABI. Toto makro by tedy mohlo být dobrým zdrojem informací o záměrech vývojáře jádra, ale nijak to negarantuje, že se požadavky na stabilitu budou vztahovat pouze na označené sledovací body.
Před Jedenáctým Real Time Linux Workshop v Drážďanech se setkala malá skupina, která diskutovala další vývoj práce na preempci v reálném čase v linuxovém jádře. Tento „minisummit“ pokryl širokou škálu témat, ale byl zaměřen na přímočarý cíl: Pokračující zlepšování možností Linuxu běžícího v reálném čase a začlenění patchů preempce v reálném čase do jádra.
Účastnili se: Stefan Assmann, Jan Blunck, Jonathan Corbet, Sven-Thorsten Dietrich, Thomas Gleixner, Darren Hart, John Kacur, Paul McKenney, Ingo Molnár, Oleg Nesterov, Steven Rostedt, Frederic Weisbecker, Clark Williams a Peter Zijlstra. Společně reprezentovali několik firem, které pracují v oblasti Linuxu běžícího v reálném čase; k jednomu stolu přinesli spoustu zkušeností s požadavky zákazníků. Diskuze byla poněkud nestrukturovaná – neexistovala žádná formální agenda – ale pokryto bylo mnoho užitečných témat.
… se v diskuzi objevila brzy. Tato vlastnost byla do hlavní řady začleněna v jádře 2.6.30; v situacích, kdy se pracuje v reálném čase, je užitečná, protože umožňuje priorizovat obsluhu přerušení a plánovat ji stejně jako jakýkoliv jiný proces. Jedna část kódu pro obsluhu přerušení ve vláknech nicméně zůstala mimo hlavní řadu: Ten kousek, který vynucuje, aby obsluhu ve vláknech používaly všechny ovladače. Neplánuje se přesunutí tohoto kódu do hlavní řady; přechod na novější způsob toho, jak dělat věci, bude záležitostí přesvědčování autorů ovladačů.
Přijetí v hlavní řadě je zatím malé; tuto vlastnost skutečně používá jenom pár ovladačů. To se však začíná měnit, jedním příkladem je vrstva SCSI. SCSI vždycky měla relativně těžkotonážní kód pro obsluhu přerušení a práce probíhala v jednovláknových pracovních frontách – tento kód se do kontextu procesu může přemístit poměrně přirozeně. Vývojáři SCSI prý uvažují nad možným přechodem k obsluze přerušení ve vláknech v blízké budoucnosti. Také se objevily návrhy, že by se tímto směrem mohl přesunout síťový stack.
… [system management interrupt, SMI] je úplně jiný druh problému. K těmto přerušením dochází na velmi nízké úrovni hardwaru a jsou obsluhována kódem BIOSu. Často mají za úkol sledování hardwaru od jednoduchého měření teploty po mnohem složitější operace, které běžně se softwarem na úrovni BIOSu spojovány nejsou. SMI jsou pro operační systém téměř zcela neviditelné a obecně nepodléhají řízení na této úrovni, ale v několika důležitých způsobech se projevují: Na měřitelnou dobu si pro sebe zabírají od jednoho po všechna CPU v systému a mohou přitom měnit důležité parametry, jako je takt hodin. SMI na některém hardwaru může běžet překvapivě dlouho; jeden prodejce prodává systémy, kde SMI pro správu pamětí ECC běží každé 3 minuty po dobu 200 µs. To je dost na to, aby se vnesl chaos do splnění kterékoliv latenční lhůty, do které se operační systém pokouší vejít.
Vyřešit problém s SMI je výzva. Na některém hardwaru je možné SMI vypnout, ale nikdy není jisté, jaké to může mít důsledky; pokud se CPU rozteče na hromádku křemíku, výsledné latence budou horší než předtím. Sdílení informací o problémech s SMI může být obtížné, protože mnoho z lidí pracujících v této oblasti pracuje s tím, že s výrobci mají dohodu o utajování informací; to je dost nešťastné, protože někteří výrobci se latencím spojeným s SMI vyhnuli lépe než jiní. V současnosti se objevil nástroj (hwlat_detector), který měří latenci SMI, takže o tomto tématu pravděpodobně uvidíme veřejnější informace. A s trochu štěstí začnou výrobci problém řešit.
Ne všechny problémy s latencemi v hardwaru jsou ale spojeny s SMI; významným zdrojem problémů s latencemi mohou být také hypervizory.
S tím spojené téma jsou hardwarové změny, které obsluha SMI vyvolá. Pokud BIOS rozhodne, že se systém přehřívá, může reagovat snížením taktu hodin nebo napětí procesoru. Na systému orientovaném na propustnost to dost dobře může být správné rozhodnutí, ale když jsou důležité latence, zpomalení procesoru může být chybou – aplikace se nemusí vejít do limitu. Lepším rozhodnutím by zde mohlo být vypnout některé procesory a ostatní nechat běžet plnou rychlostí. Co je zde skutečně potřeba, je způsob, jakým dostat informace do uživatelského prostoru, aby se mohlo rozhodnout tam.
… je vždycky u tohoto druhu vývoje softwaru problém; jak mohou vývojáři vědět, že opravdu věci zlepšují? Jsou k dispozici různé testovací nástroje (například RTMB), ale žádná kompletní a integrovaná testovací kolekce neexistuje. Mluvilo se o pokusu přesunout více kódu pro testování v reálném čase do Projektu testování Linuxu [Linux Test Project], ale LTP je obrovský kus kódu. Testy pro reálný čas tedy mohou zůstat osamoceny, ale bylo by přinejmenším hezké standardizovat nastavení testů a výstupní formáty, aby se umožnila automatizace testování. Někteří preferovali výstup v XML, ale bude fér, když řekneme, že XML v této společnosti není všeobecně oblíbeno.
… [Big Kernel Lock, BKL] při vývoji pro běh v reálném čase zůstává na seznamu k vyřízení z několika důvodů. Jedním z nich je to, že přestože byl vytlačen z většiny vnitřního kódu, může BKL stále způsobovat dlouhé latence. Další je, že odstranění BKL je pravděpodobně částí ceny, kterou bude potřeba zaplatit za eventuální začlenění spících v cyklu běžících zámků [spinlock] do hlavní řady. Možnost přerušit kód běžící pod BKL preempcí byla v jádře 2.6.26 odstraněna, což bylo přímo motivováno výkonnostní regresí, kterou způsobilo přepsání semaforů, ale také to bylo považováno za způsob, jakým lze povzbudit pokusy o odstranění BKL ze strany těch, kdo se o latence zajímají.
Většina z té těžké práce, která byla zapotřebí pro odstranění BKL, byla odvedena; jeden velký nedodělaný kousek je konverze reiserfs, na čemž pracuje Frederic Weisbecker. Poté už zbude spousta práce pro pěšáky: zjistit, co (pokud něco) je chráněno pomocí volání lock_kernel(), a obalit to správným zamykáním. Strom "tip" má větev (rt/kill-the-bkl), kde je tato práce koordinována a sbírána.
… také není zcela vyřešený problém. Signály jsou ve skutečnosti vždy problematické jak pro ty, kdo je implementují, tak pro uživatele. V kontextu běhu v reálném čase má doručování signálů specifické problémy s latencemi – doručování signálů do skupin vláken zahrnuje algoritmus o složitosti O(n), který určuje, na které specifické vlákno se zaměřit; projít tímto kódem může způsobit příliš vysoké latence. V doručovací cestě jsou také nějaké zámky, které narušují doručování signálů v kontextu přerušení v reálném čase.
Všichni souhlasí, že správným řešením je vyhnout se v aplikacích signálům všude, kde je to možné. Pro události časovače lze například použít timerfd(). Všichni ale také souhlasí, že aplikace budou nadále používat signály a je tedy nutné nějak zajistit, aby fungovaly. Pravděpodobným řešením bude odstranit většinu práce z okamžité cesty doručování signálu. Doručení signálu by pouze zařadilo informace do fronty a nastavilo bit ve struktuře úlohy [task struct]; skutečná práce by se poté odvedla v kontextu přijímajícího procesu. Tato práce sice stále může být drahá, ale latence způsobené používáním signálů by přinejmenším dopadly na aplikaci, která je používá, místo na náhodné části systému.
… bylo téma postranní diskuze, která poskytla několik základních doporučení. Nejlepší API, které je možné použít, je základní rozhraní pthread; postupem času bylo dostatečně optimalizováno. SYSV IPC je nejlépe se vyhnout. Sady CPU [cpusets] fungují pro izolaci CPU lépe než mechanismus příchylnosti [affinity]. Obecně by si vývojáři měli uvědomit, že vytěžit ze systému běžícího v reálném čase nejlepší výkonnost bude vyžadovat určité množství snahy a manuálního ladění. Linux pro reálný čas umožňuje priorizovat věci, jako je obsluha přerušení, ale tvrdou práci spočívající ve zjišťování, které priority by to měly být, musí odvést vývojáři a správci. Bylo potvrzeno, že rozhraní, která jsou poskytována správcům, v současnosti není snadné používat; například může být obtížné identifikovat vlákna přerušení. Nástroj tuna od Red Hatu v tomto ohledu může pomoci, ale je potřeba toho udělat více.
… byla na setkání běžným tématem. Obecné pravidlo je, že vývojáři běhu v reálném čase se na záležitosti spojené se škálovatelností specificky nezaměřovali, ale je zde zájem o používání aplikací běžících v reálném čase na větších systémech, což přináší problémy. Jádro pro běh v reálném čase má tendenci narazit na problémy se škálovatelností dříve než jádro hlavní řady; to bylo popsáno jako systém včasného varování, který upozorňuje na záležitosti, se kterými se hlavní řada bude potýkat za pět let od teď. Realtimový strom tedy bude škálovat hůře než hlavní řada, ale oprava problémů v něm bude nakonec užitečná i pro uživatele v hlavní řadě.
Darren Hart prezentoval několik grafů obsahujících výsledky části práce Johna Stultze, které ukazovaly dopad běhu jádra pro běh v reálném čase na systému s 24 procesory. Když se běželo v jakémkoliv kromě jednoprocesorového režimu, jádro zavleklo při vhodně patologické zátěži přibližně 50% postih výkonnosti – značná cena. Zajímavé však je, že když se z jádra pro reálný čas odstraní změny zamykání a všechny ostatní změny se nechají na místě, většina výkonnostních postihů zmizí. To Darrena vedlo k otázce, jestli by nebylo vhodné poskytnout možnost hybridního běhu v případě, že nejsou pevné požadavky na latenci.
V jiných situacích se v jádře pro běh v reálném čase obecně objevuje degradace výkonnosti počínající u osmi CPU, přičemž šestnáct již vykazuje neakceptovatelnou režii.
Jak se stává, nikdo nechápe, kde se bere výkonnostní postih způsobovaný zamykáním v reálném čase. Na vině by mohly být spící spinlocky, ale značné podezření je také zaměřeno na zámky čtenář-zapisovatel [reader-writer lock, rwlock]. V hlavní řadě rwzámky umožňují několika čtenářům běžet paralelně; v jádře pro běh v reálném čase běží pouze jeden čtenář zároveň. Tato změna je nutná, aby fungovalo dědění priorit; dědění priorit je za přítomnosti několika čtenářů složitý problém. Jedním zjevným závěrem, který vychází z tohoto pozorování, je, že rwzámky by neměly implementovat dědění priority. Proti tomuto návrhu se nicméně objevil odpor; dědění priorit je důležité v situacích, kdy by proces o nejvyšší prioritě měl vždy běžet tak rychle, jak je to možné.
Alternativou ke změně rwzámků je jednoduše je úplně přestat používat. Obvyklý způsob, jakým se nahrazuje rwzámek, je jeho nahrazení schématem pro čtení-kopírování-zápis [read-copy-update]. Přechod k RCU škálovatelnost zlepší, ale pravděpodobně za cenu zvýšení složitosti. Před zahájením této snahy je důležité zjistit, jak velkou část problému rwzámky opravdu způsobují. V blízké budoucnosti proběhne nějaký výzkum, který se bude snažit lépe pochopit zdroj problémů se škálovatelností.
Další problém jsou proměnné specifické pro CPU, které fungují tak, že zakazují preempci, když se specifická proměnná využívá. Zákaz preempce je pro vývojáře běhu v reálném čase zapovězená oblast, takže jsou proměnné specifické pro CPU místo toho chráněny spícími zámky. To zvyšuje režii. Tento problém je obzvláště akutní u alokací paměti na úrovni slabu, které proměnné specifické pro CPU využívají výrazně.
Řešení má mnoho podob. Nakonec vznikne slab alokátor přívětivější k běhu v reálném čase, pravděpodobně varianta SLQB. Minimalizace využívání proměnných specifických pro CPU dává při běhu v reálném čase smysl obecně. Také existují schémata zahrnující vytváření virtuálních „CPU“, takže i procesy běžící na stejném procesoru by mohly mít své vlastní „pro CPU specifické“ proměnné. To pro tyto proměnné výrazně snižuje soupeření za cenu lehce zvětšeného otisku v cache.
Staré jednoduché zámky také mohou představovat problém: dbench běžící na šestnáctiprocesorovém systému během workshopu ukázal 90% omezení propustnosti, přičemž procesory polovinu času nebyly vytíženy. Problémem se v tomto případě ukazuje být dcache_lock, jeden z mála zbývajících globálních spinlocků v jádře. Strom pro běh v reálném čase pociťuje vliv tohoto zámku silněji z několika důvodů. Jedním je, že vlákna držící zámek lze přerušit preempcí; to vede k delší době držení zámku a častějšímu přepínání kontextu. Další je, že spící spinlocky jsou prostě komplikovanější, obzvláště na pomalejší kódové cestě, kde se soupeří. Zamykací primitiva sama o sobě tedy vyžadují více CPU.
Řešení tohoto konkrétního problému může spočívat pouze v eliminaci globálního dcache_lock. Nick Piggin má sadu patchů, která se o to postará, ale ta ještě nebyla ve stromě pro běh v reálném čase testována.
Běh v reálném čase ztěžuje život plánovači. Na běžném systému může plánovač optimalizovat pro celkovou propustnost systému. Omezení vynucená během v reálném čase ale vyžadují, aby plánovač mnohem agresivněji reagoval na události. Přibývá tedy přepínání kontextu a zvyšuje se pravděpodobnost přechodu procesů mezi CPU – to je lepší pro omezenou dobu odezvy, ale horší pro propustnost. Nezdá se, že existuje praktický způsob, jak od plánovače získat konzistentně dobrá rozhodnutí, až bude škálovat na něco relativně velkého – řekněme na 128 CPU.
Určitý zájem je o plánovače orientované na časový limit [deadline scheduler]. Přidání plánovače „nejprve nejbližší časový limit“ nebo podobného by mohlo být pro vývojáře aplikací užitečné, ale nikdo podle všeho nemá pocit, že takový plánovač by škáloval lépe než současný kód.
Toto vše znamená, že aplikace bežící v reálném čase na takovémto systému musí běžet odděleně. Když je specifické CPU vyhrazeno pro specifické procesy, problém s plánováním se zjednoduší. Oddělení vyžaduje práci na straně administrátora, ale pro větší systémy je to, zdá se, nevyhnutelné.
Zde nepomáhá to, že na linuxovém systému je stále obtížné dosáhnout úplné izolace CPU. Určité druhy operací, jako je vyprazdňování pracovních front, se stále mohou přelít na procesor, který byl vyhrazen pro specifický proces. Když se někdo pokouší vyhradit CPU pro nějakou úlohu, je obecně problém cokoliv, co zahrnuje přerušení – jak přerušení od zařízení, tak meziprocesorová přerušení. Namíření přerušení od zařízení na specifický procesor není tak těžké, i když nástroje pro správu by se v tomto ohledu mohly zlepšit, ale vyhnout se meziprocesorovým přerušením je v současnosti obtížnější; kód generující IPI je potřeba revidovat a pokud možno upravit tak, aby se zabránilo přerušování procesorů, které ve skutečnosti nemusí nic dělat.
![[Skupinové foto]](http://lwn.net/images/conf/rtlws11/rt-summit-sm.jpg)
Integrace správy přerušení do současného kódu sad CPU [cpuset] a kontrolních skupin [control group] by bylo užitečné pro správce systémů. Zdá se ale, že to je obtížnější úkol; Paul Jackson, původní vývojář sad cpu, byl silně proti návrhu snažit se do nich zahrnout správu přerušení. Pro tuto správu chybí dobrá abstrakce, i když obecná IRQ vrstva pomáhá. Na setkání bylo takové mínění, že jde o řešitelný problém; pokud ho bude možné vyřešit pro architekturu x86, ostatní architektury nakonec budou následovat.
Pro izolaci CPU je také důležitým krokem přechod na zcela beztikové jádro. V tomto směru byla nedávno odvedena nějaká práce, ale i tak jí zbývá hodně.
Překvapivě se objevily obavy ohledně stabilního jaderného ABI. Nabídky Linuxu pro „podnikové“ nasazení od distributorů obvykle zahrnují slib, že interní jaderná rozhraní se nebudou měnit. Podnikové distribuce pro běh v reálném čase nicméně tvoří výjimku z tohoto pravidla; kód se jednoduše příliš mění na to, aby takový slib byl praktický. Tato výjimka přirozeně vývojářům zjednodušila práci na kódu; také umožnila zákazníkům rychle získat nový kód. Jsou tedy určité obavy, že jakmile se zbývající kód pro běh v reálném čase začlenění do hlavní řady, budou se něj vztahovat stejná omezení ohledně jaderného ABI. Zde nicméně není jisté, jestli to tak opravdu bude; zákazníci, kteří kupují systémy běžící v reálném čase, se většinou více zajímají o nejnovější technologie a jsou tedy ochotnější vyrovnat se s většími změnami.
… byla také krátce diskutována. Nějaké věci zbývají, mezi nimi:
Více práce na SMP, obzvláště na NUMA systémech.
Nečinná smyčka v reálném čase [realtime idle loop]. Zde je obvyklé napětí mezi snahou zachovat co nejlepší dobu odezvy a minimalizací spotřeby energie.
Podpora hardwarem asistovaných operací – věcí, jako je hardware akcelerující šifrování.
Eliminace tiku časovače.
Synchronizace událostí hodin mezi CPU. Synchronizace hodin je vždy výzva, v tomto případě je to komplikované faktem, že určitá odchylka hodin může být na SMP systému výhodná – pokud jsou události hodin striktně synchronní, procesory se snaží dělat věci naráz a vzrůstá soupeření o zámky.
Záležitost pro blízkou budoucnost je pojmenování spinlocků. Začlenění kódu spících spinlocků vyžaduje způsob, jak rozlišit tradiční v cyklu běžící zámky a novější typ, který může na systému běžícím v reálném čase spát. Nejlepším řešením – teoreticky – je přejmenovat spící zámky na něco jako je lock_t, ale to by byla obrovská změna týkající se několika tisíc souborů. Vývojáři proto zvažují dát místo toho nové jméno nespícím zámkům. Těch je podstatně méně, takže jejich přejmenování na něco jako atomic_spinlock by bylo mnohem méně rušivé.
Trochu se diskutovalo o nejlepším jméně pro „atomické spinlocky“; mohly by to být „vnitřní zámky“ [core locks], „malé jaderné zámky“ [little kernel locks] nebo „děsivé zámky“ [dread locks]. Z diskuze nicméně vyplynulo, že co se týče těchto dvou typů zámků, ke zmatkům dochází i v této skupině, která jim rozumí lépe než kdokoliv jiný. To naznačuje, že pojmenovávat by se mělo velice pečlivě tak, aby sémantika byla jasná a jméno odrazovalo od použití nespících zámků. Pokud se sémantika spinlock_t bude měnit, mělo by se měnit i jméno – to podporuje myšlenku masivního přejmenovávání zámků bez ohledu na to, jak rušivé to bude.
Jestli by taková změna byla akceptovatelná, je ale otevřená otázka. Prozatím bude k revizím připraveno jak malé, tak velké přejmenovávání. Tato záležitost bude možná přednesena na říjnovém Jaderném summitu, aby ke konečnému rozhodnutí došlo tam.
… pro vývojáře běhu v reálném čase se v diskuzi objevily několikrát. Pro optimalizaci aktualizací je několik nástrojů, ale jsou roztříštěné a ne vždy se používají snadno. A navíc se říká, že je potřeba nástroj s grafickým rozhraním, protože jinak ho spousta uživatelů prostě nebude brát vážně – do této role je podle všeho předurčen nástroj perf, součást jaderného subsystému pro „události výkonnosti“. Ten již nyní dokáže zvládnout mnoho z požadovaných úloh – například sledování latence – a nové vlastnosti jsou přidávány. Nástroj „tuna“ bude možná rozšířen tak, aby perfu poskytl hezčí rozhraní.
Vysoko na seznamu užitečných vlastností se zdají být i sledovací body v uživatelském prostoru [user-space tracepoints]. Nejlepší by bylo tyto sledovací body nějak integrovat do ftrace, alternativně by bylo možné sbírat data z uživatelského prostoru odděleně a integrovat je s daty ze sledování jádra při následném zpracování. To však vede k problémům ohledně synchronizace hodin, které nikdy není jednoduché vyřešit.
Z poslední části setkání se stala série neformálních diskuzí a pokusů o programování. Účastníci toto setkání považovali za užitečné, protože se všichni hodně dozvěděli. Samozřejmě vzniklo několik úkolů, které je potřeba udělat, včetně více testování, aby byl pochopen problém se škálovatelností, zajistit větší přijetí obsluhy přerušení ve vláknech, vyřešit problém pojmenování spinlocků, zlepšit nástroje a další. Pro všechny spousta práce. Autor článku byl však ujištěn, že tato práce bude hotova a začleněna příští rok – a tentokrát opravdu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.