Společnost OpenAI představila svůj nejnovější AI model GPT-4o (o jako omni, tj. vše). Nově také "vidí" a "slyší". Videoukázky na 𝕏 nebo YouTube.
Ondřej Filip publikoval reportáž z ceremonie podpisu kořenové zóny DNS. Zhlédnout lze také jeho nedávnou přednášku Jak se podepisuje kořenová zóna Internetu v rámci cyklu Fyzikální čtvrtky FEL ČVUT.
Společnost BenQ uvádí na trh novou řadu monitorů RD určenou pro programátory. První z nich je RD240Q.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »GHC (Glasgow Haskell Compiler, Wikipedie), tj. překladač funkcionálního programovacího jazyka Haskell (Wikipedie), byl vydán ve verzi 9.10.1. Přehled novinek v poznámkách k vydání.
Po 9 týdnech vývoje od vydání Linuxu 6.8 oznámil Linus Torvalds vydání Linuxu 6.9. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.
Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
Současné vývojové jádro je 2.6.32-rc4, vydané 11. října. Obsahuje spoustu malých oprav a pár nových SCSI ovladačů. Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.
2.6.32-rc5 lze očekávat 15. října, těsně předtím, než Linus odcestuje do Tokya na 2009 Kernel Summit.
Současné stabilní jádro je 2.6.31.4 vydané (společně s 2.6.27.37) 12. října. Tyto aktualizace obsahují další sadu důležitých oprav těchto jader; trochu více informací o změnách v 2.6.31.4 obsahuje toto shrnutí od Andyho Whitcrofta.
Nástroje pro statickou analýzu mohou mít při vývojovém procesu velkou hodnotu; často nacházejí chyby, které uniknou při revizích a které potenciálně mohou v kódu žít léta. Linux měl výhodu v podobě chybových hlášení nástrojů Coverity, ale tyto nástroje jsou proprietární a svobodné nástroje pro statickou analýzu za svými proprietárními alternativami bohužel vždycky zaostávaly.
To se nezmění přes noc, ale na startovním bloku se objevuje nový závodník – Stanse; nedávno byla v jaderné e-mailové konferenci
Zjevně by bylo hezké rozšířit Stanse o další testy. Mnoho jaderných vývojářů by se toho ale mohlo zaleknout; Stanse je aplikace v Javě a testovací pravidla musí být napsána v XML. To omezuje přidávání pravidel na ty, kdo se vyznají v jaderném kódu a zároveň jsou schopni pracovat v prostředí Java/XML.
Kernel Summit 2009 se bude konat 19. a 20. října v Tokyu těsně před Japan Linux Symposium. Bude to poprvé, co se summit bude konat v Asii. Pokud nic jiného, pohled na spoustu jaderných vývojářů utržených ze řetězu v Akihabaře by mohl být zábavný.
Byl zaslán návrh agendy; jako obvykle poskytuje náhled na to, jaké problémy jsou v současnosti považovány za nejtíživější. Podle tradice z minulých let se na Summitu věnuje jenom málo času specifickým technickým záležitostem; tento druh problémů se obvykle nejlépe řeší v mailových konferencích s kódem. Setkání tváří v tvář je naopak nejlepší pro řešení procesních záležitostí.
Agenda tentokrát zahrnuje diskuzi se (zatím nejmenovanými) koncovými uživateli jak z embedded světa, tak ze světa velkých podniků. Zástupci velkých podniků jsou na těchto setkáních poměrně běžnými účastníky, ale přítomnost embedded komunity je novinka. Se štěstím tato diskuze podpoří trend, ve kterém by se prodejci embedded systémů více účastnili na vývojovém procesu. Druhý den bude na Summitu ke slyšení uživatel, kterého si běžně s embedded systémy nespojujeme: Bude se konat sezení o používání Linuxu Googlem a o problémech, na které narazili.
Další diskuze se týká věčného „regrese a kvalita jádra“. Odděleně se potom bude mluvit o výkonnostních regresích konkrétně; pravděpodobně se zde naváže na podobnou diskuzi jaderných vývojářů na LinuxCon. Také se bude diskutovat o tom, jak fungují stromy linux-next a staging, proběhne otevřená diskuze o zlepšování vývojového procesu.
Co se technického hlediska týče, summit začne shrnutím z nedávných minisummitů. Události výkonnosti a sledování zabírají velký časový podíl; část z něj bude věnována předvedení toho, co lze udělat pomocí perf, ftrace a timechart. Bude se diskutovat o rozšíření používání stromu zařízení na další architektury, zlepšování podpory obecné architektury a začlenění zbývajících patchů pro preempci v reálném čase. „Hodina programování“ zavedená loni je zpět; padl návrh, že tématem by letos mohlo být odstraňování velkého jaderného zámku.
Jonathan Corbet, redaktor LWN, bude jako vždy na místě, aby mohl o všem informovat. Články budou vydány hned, jak budou hotové; zůstaňte na příjmu.
Obecné pravidlo je, že všechny nové vlastnosti by se do jádra měly přidávat během dvoutýdenního začleňovacího okna. Je tu ale určitá výjimka pro nové ovladače zařízení. Dobře napsaný ovladač by neměl být schopen vyvolat regrese nikde jinde v jádře, takže má často význam dostat ho k uživatelům tak rychle, jak je to jen možné. Ovladače se tedy často dostávají do hlavní řady, i když jsou ostatní velké změny zablokovány.
Jak ale ukazuje nedávný požadavek na přetažení oprav SCSI, jsou zde omezení. Tento požadavek zahrnoval dva nové ovladače pro high-endové SCSI úložiště. Ty Linuse z několika důvodů naštvaly: Rád by, aby se správci subsystémů snažili začlenit ovladače během začleňovacího okna. Myslí si, že „výjimka pro ovladače“ je hlavně užitečná pro zařízení na úrovni dostupné pro běžné zákazníky, a zmíněný ovladač nebyl malý kousek kódu, ale monstrum o 50 000 řádcích. Ovladač byl nakonec začleněn do 2.6.32-rc4, ale Linus dal jasně najevo, že takový kód by raději dostal během začleňovacího okna.
Rozhovor se poté posunul k tomu, že tento ovladač měl jít spíše do stromu staging; ti, kdo se na něj dívali, ho nepopsali jako nejlepší kód dne. Správce SCSI James Bottomley ale považuje strom staging hlavně za místo, kde jsou řešeny záležitosti ohledně ABI do uživatelského prostoru. Věří, že záležitosti ohledně pouhé kvality kódu je lepší řešit přímo ve stromě SCSI. Ostatní nesouhlasí; konečné slovo ale má vždy správce konkrétního subsystému. Jestliže se rozhodne přijmout nový ovladač přímo do stromu subsystému, nikdo jiný ho odtud nemůže vystrnadit.
Výsledkem této diskuze bylo také další potenciální využití stromu staging – jako místo posledního odpočinku pro staré ovladače na jejich cestě z jádra ven. Správce staging Greg Kroah-Hartman poznamenal:
Tento nápad je nicméně hypotetický až do doby, dokud někdo strom staging tímto způsobem nepoužije. Je obtížné si představit, že by se proti degradaci do staging neobjevily žádné protesty; první pokus to udělat bude zajímavé pozorovat.
Jeden z dlouhodobých zádrhelů síťování inspirovaného BSD je to, že síťové rozhraní jsou poměrně podivným druhem zařízení. Žijí ve vlastním jmenném prostoru, neobjevují se v /dev a obecně se nedrží myšlenky „všechno je soubor“, která ovlivňuje většinu POSIXového API. Unixový způsob síťování fungoval téměř 30 let, je tedy pravděpodobné, že jenom pár lidí očekávalo vážně míněný patch, který se pokusí něco změnit.
Tento patch od „Narendra K“ z Dellu nicméně dělá přesně to a poměrně překvapivými způsoby. S tímto patchem je každé síťové rozhraní spojeno se znakovým zařízením. Toto zařízení je mimořádně neužitečné: Jakýkoliv pokus ho otevřít vždy vrátí ENOSYS. Jediný skutečný důvod pro jeho existenci je generovat události pro udev, který následně může generovat pro rozhraní alternativní jména.
K čemu tato změna? Prodejci systémů a správci jsou již unaveni z toho, že se jména jejich síťových rozhraní při každém bootu mění. Nedeterministické pojmenovávání rozhraní je výsledkem několika faktorů, mezi něž patří podivné chování BIOSu a způsob, jakým současná jádra vyhledávají zařízení paralelním připojováním za běhu [hot-plug]. Když se změní jméno rozhraní, konfigurační skripty mohou být zmateny; funkční síť je konečným výsledkem jenom málokdy. Tomuto zmatku se lze částečně vyhnout pečlivou konfigurací rozhraní podle jejich MAC adres, ale i to může selhat při pokusu o rychlou obnovu provozu po selhání tím, že se vymění celý server.
Výrobci se pokusili část těchto potíží obejít na úrovni hardwaru. Stroje od Dellu jsou navrženy tak, aby ve většině případů načítaly síťová rozhraní ve stejném pořadí. HP blade servery mohou konfigurovat svou MAC adresu při zapnutí. Počet hardwarových hacků, které budou výrobci zkoušet, aby problém vyřešili, je ale omezen. Každý, kdo chce plně pochopit problém, který tu máme, si může přečíst tuto zprávu od Matta Domsche.
Proto vznikl patch, který udevu umožní vytvářet pro každé rozhraní pseudojména založená na kritériích, jako je číslo PCI slotu, popis šasi nebo na čemkoliv jiném, co může dávat smysl. Patch je propojen s knihovnou libnetdevname, která tato pseudojména mapuje na skutečná jména zařízení, jež lze potom využít pro systémová volání socketů.
Patch byl přijat poněkud nevlídně; některým připadá jako obcházení problému, který by bylo možné vyřešit jinými způsoby. Diskuze nicméně jasně ukázala, že problém existuje, takže na nějaké řešení nakonec pravděpodobně dojde – pravděpodobně v udevu, což je ostatně prostředek, kterým se řeší pojmenovávání všech ostatních zařízení v systému. Očekávejme tedy, že něco se do jádra dostane, i když současný návrh se bude pravděpodobně trochu vyvíjet, než bude považován za vhodný k začlenění.
Bylo nebylo, Linux byl kdysi na 32bitových systémech omezen na 1 GB fyzické paměti. Tento limit byl zaveden dvěma technickými rozhodnutími: Procesy běžely se stejnými tabulkami stránek jak v jaderném, tak v uživatelském režimu a veškerá fyzická paměť musela být jádrem adresovatelná přímo. Když se nevyměňují tabulky stránek při každém přechodu mezi jádrem a uživatelským prostorem, má to významné výkonnostní zisky, ale vynucuje to, aby oba režimy sdílely stejný adresovací prostor o velikosti 4 GB. Požadavek na přímou adresovatelnost znamenal, že celková fyzická paměť nemohla překročit velikost adresového prostoru virtuální paměti přidělené jádru. A dokonce nebyl k dispozici ani celý jaderný prostor, protože bylo potřeba ponechat nějaké místo pro I/O paměť, vmalloc() a tak dál. Normální dělení je 3 GB pro uživatelský prostor a 1 GB pro jádro; to omezuje systémy na o něco méně než 1 GB fyzické paměti.
Tento problém byl opraven konceptem „horní paměti“: Paměti, kterou nelze z jádra adresovat přímo. Jádro většinou nepotřebuje s velkou části paměti v systému manipulovat; k většině stránek v uživatelském prostoru se přistupuje pouze v uživatelském režimu. Jádro nicméně příležitostně potřebuje dosáhnout na kteroukoliv stránku v systému – příkladem může být nulování nových stránek nebo čtení parametrů systémových volání z uživatelského prostoru. Vzhledem k tomu, že stránky v horní paměti nemohou žít ve virtuálním adresovém prostoru jádra trvale, je zapotřebí mechanismus, který dočasně vytvoří adresu v jaderném prostoru pro stránky v horní paměti.
Tento mechanismus se nazývá kmap(); přebírá ukazatel na struct page a vrací virtuální adresu v jaderném prostoru pro tuto stránku. Když jádro stránku již nepoužívá, musí použít kunmap(), aby se stránka odmapovala a adresa byla k dispozici pro další mapování. kmap() funguje, ale může být pomalé; musí vyprázdnit TLB a za určitých okolností i vyvolat meziprocesorová přerušení pro každé mapování. Linus cenu horní paměti nedávno komentoval takto:
Veškerá tato drahá práce je nutná k tomu, aby mapování v jaderném prostoru zůstala konzistentní na všech procesorech v systému, i když mnoho z nich se používá pouze krátce a pouze na jednom CPU.
Pro zlepšení výkonnosti jaderní vývojáři zavedli speciální verzi:
void *kmap_atomic(struct page *page, enum km_type idx);
| Sloty pro atomický kmap |
|---|
| KM_BOUNCE_READ |
| KM_SKB_SUNRPC_DATA |
| KM_SKB_DATA_SOFTIRQ |
| KM_USER0 |
| KM_USER1 |
| KM_BIO_SRC_IRQ |
| KM_BIO_DST_IRQ |
| KM_PTE0 |
| KM_PTE1 |
| KM_IRQ0 |
| KM_IRQ1 |
| KM_SOFTIRQ0 |
| KM_SOFTIRQ1 |
| KM_SYNC_ICACHE |
| KM_SYNC_DCACHE |
| KM_UML_USERCOPY |
| KM_IRQ_PTE |
| KM_NMI |
| KM_NMI_PTE |
Tato funkce se od kmap() v mnoha důležitých ohledech liší. Vytváří mapování pouze na současném CPU, takže není nutné kvůli němu otravovat ostatní procesory. Také vytváří mapování s použitím jedné z velmi mála adres v jaderném prostoru – volající musí určit, kterou z těchto adres použít, pomocí argumentu idx; tyto adresy jsou specifikovány sadou konstant pro „sloty“. Například KM_USER0 a KM_USER1 jsou připraveny pro kód volaný přímo z uživatelského kontextu – obecně pro implementace systémových volání. KM_PTE0 se používají pro operace s tabulkou stránek, KM_SOFTIRQ0 se používá v režimu softwarových přerušení atd. V současných jádrech je těchto slotů definováno přibližně dvacet; seznam platný pro 2.6.32 vizte v tabulce napravo.
Použití pevných slotů vyžaduje, aby tato mapování byla atomická – odtud jméno kmap_atomic(). Pokud by kód držící atomický kmap bylo možné přerušit preempcí, vlákno, které poběží jako další, může použít stejné sloty s nešťastnými výsledky. To, že je atomické mapování specifické pro konkrétní CPU, znamená, že jakákoliv migrace mezi CPU by znamenala katastrofu. Zde stojí za to poznamenat, že není žádná další ochrana proti použití specifických slotů; pokud se dvě funkce v daném řetězci volání neshodnou o použití KM_USER0, stanou se ošklivé věci. V praxi se nicméně zdá, že tento problém se neprojevuje.
API se během let příliš neměnilo, ale Peter Zijlstra se nedávno rozhodl, že by se mu hodil nový nátěr. Výsledkem je série patchů, která toto důležité rozhraní mění a opravuje výsledné problémy s překladem u více než 200 souborů. Změna je koncepčně jednoduchá: Sloty mizí a rozsah adres se místo toho spravuje jako zásobník. Uživatele kmap_atomic() konec konců nezajímá, jakou adresu dostanou; chtějí jenom adresu, kterou nepoužívá nikdo jiný. Nové API nevynucuje, aby se operace mapování a odmapování správně vnořovaly, ale jejich atomická povaha znamená, že k tomu obecně bude docházet i tak.
Zdá, že začlenění této změny není příliš zpochybňováno; Linus to uvítal: Myslím si, že tak jsme to měli udělat už původně. Objevily se nicméně dohady ohledně pojmenovávání v první verzi patche (kmap_atomic() se měnilo na kmap_atomic_push()), ale to bylo snadno opraveno v druhé iteraci.
Je také zajímavé se podívat na to, jak byla tato série patchů přepracována. První verze byla jediný patch, který všechny změny provedl naráz. V reakci na revize Peter druhou verzi rozdělil na čtyři kroky:
Ujištění se, že jsou všechny atomické kmap vytvářeny a rušeny se striktním vnořováním. V kódu bylo několik míst, kde tomu tak nebylo; oprava byla většinou záležitostí změny pořadí několika volání kunmap_atomic().
Změna na režim založený na zásobníku, aniž by se měnil prototyp kmap_atomic(). Po tomto patchi kmap_atomic() jednoduše ignoruje argument idx.
Prototyp kmap_atomic() ztrácí argument idx; to je zatím největší patch ze série.
Oprava různých závěrečných detailů.
Když budou věci provedeny takto, značně se zjednoduší ladění jakýchkoliv podivných problémů, které budou výsledkem těchto změn. Nejvýznamnější změna, co se týče fungování jádra, je krok 2, takže to je patch, který s největší pravděpodobností bude činit problémy. Tato organizace nicméně zajišťuje, že bude patch relativně malý, takže dohledání všech zbývajících chyb by mělo být relativně jednoduché. Na rozdíl od toho opravdu obrovský patch (krok 3) by neměl binárku jádra změnit vůbec, takže šance na to, že bude bezproblémový, jsou relativně velké.
Zbývá jenom tuto změnu začlenit. Pro 2.6.32 je příliš pozdě, ale vložení do linux-next s velkou pravděpodobností vyvolá velký počet konfliktů mezi patchi. To je nicméně běžný problém s rozsáhlými patchi, jako je tento; vývojáři se ale během let naučili, jak je spravovat oproti rychle se měnícímu jádru.
Originál tohoto článku pro LWN.net napsal Greg Kroah-Hartman.
Jeden díl ze seriálu sloupků, ve kterých jsou jadernému vývojáři položeny otázky, a on se je pokouší zodpovědět. Pokud máte nezodpovězené dotazy spojené s technickými nebo procedurálními záležitostmi okolo vývoje linuxového jádra, pište je (v angličtině) původnímu autorovi.
Jak začít efektivní komunikaci s jaderným vývojářem, abych zajistil opravu svých problémů?
I přes velikost schránek většiny správců jaderných subsystémů je toto otázka, která se při rozhovorech s uživateli objevuje často, takže je dobré ji tu zodpovědět.
Nejjednodušší způsob, jak jadernému vývojáři sdělit problém, je napsat e-mail a poslat ho do konference subsystémů, který se vztahuje k oblasti, kde máte problémy, a jeho kopii také vývojářům, abyste se ujistili, že zprávu uvidí.
Jak ale zjistit, o který subsystém a kterou e-mailovou konferenci se jedná? Jádro naštěstí obsahuje seznam e-mailových konferencí a vývojářů zodpovědných za různé jaderné subsystémy. Soubor MAINTAINERS ve stromě zdrojových kódů Linuxu vyjmenovává všechny subsystémy, jméno správce, jeho e-mailovou adresu a e-mailovou konferenci, která je nejlepší pro řešení problémů. Pokud není specifikována konference, použijte výchozí adresu konference linux-kernel.
Pokud se vám podaří problém zúžit na soubor, na který se chcete zeptat, skript scripts/get_maintainer.pl ve stromě zdrojových kódů může automaticky vyhledat lidi zodpovědné za jeho poslední změnu stejně jako správce a konferenci. Například řekněme, že máte problém s ovladačem ftdi_sio, který je umístěn v drivers/usb/serial/ftdio_sio.c. Po spuštění skriptu get_maintainer.pl s parametrem -f dostanete následující:
$ scripts/get_maintainer.pl -f drivers/usb/serial/ftdi_sio.c Greg Kroah-Hartman <gregkh@suse.de> Alan Cox <alan@linux.intel.com> linux-usb@vger.kernel.org linux-kernel@vger.kernel.org
Vždy se ujistěte, že posíláte kopii do vývojové e-mailové konference, nejenom jadernému vývojáři, protože počet e-mailů, které jim přichází, je poměrně velký. Zasláním do e-mailové konference zajišťujete, že vám může pomoci kdokoliv – využíváte tak větší vývojovou komunitu – a nepřetěžujete tak již nyní přetížené správce.
Co mám dělat, když na svůj e-mail nedostanu odpověď?
Buďte vytrvalí. Jestliže nedostanete odpověď do týdne, pošlete přátelský e-mail typu „nepřehlédl jsi můj e-mail?“
Ve světě BSD je „šéf bezpečnosti“. Proč v linuxovém jádře nikdo takový není?
Je pravda, že za bezpečnost jádra Linuxu nezodpovídá jedna konkrétní osoba, této role se totiž ujala skupina vývojářů. E-mailová adresa security@kernel.org míří přímo na tyto vývojáře, kteří rychle reagují na všechny hlášené problémy.
Instrukce k tomu, jak tyto lidi kontaktovat, a pravidla okolo toho, jak pracují (týkají se zveřejňování a množství času před veřejnou opravou problému), lze najít v souboru Documentation/SecurityBugs v jádře. Pokud má někdo k těmto pravidlům otázky, klidně tento tým můžete kontaktovat a zeptat se.
Díváte se na kód BSD, hledáte v něm nové nápady a koncepty, nebo je zcela ignorujete?
Kde hledat inspiraci pro věci, které v Linuxu implementovat, je záležitost jednotlivce. Co se mě týče, na BSD jsem se nedíval už několik let, protože jsem byl zaneprázdněn věcmi, které se týkají pouze Linuxu (model ovladačů, USB, Projekt ovladač pro Linux atd.). Jiní jaderní vývojáři nicméně spolupracují s vývojáři BSD na řešení různých problémů nebo ve snaze dát dohromady fungující podporu různých typů zařízení.
V prvních dnech podpory USB v Linuxu jsem pracoval s mnoha vývojáři USB v jádru BSD, sdíleli jsme informace o tom, jak specifická zařízení fungují, aby bylo možné napsat ovladače pro oba operační systémy; celkově jsou vývojáři vůči sobě přátelští, protože pracují na řešení stejných typů problémů, i když obvykle různými způsoby.
Většina práce na plánování v reálném čase v Linuxu je založena na snaze dosáhnout co nejlepšího chování POSIXových realtime plánovacích tříd. Existují například techniky, jako je dědění priorit, které zajišťují, aby se úloha o nejvyšší prioritě skutečně mohla rozběhnout do stanovené doby. Ve zbytku světa nicméně priority a POSIX realtime nejsou považovány za nejlepší způsob, jak problém vyřešit. Místo toho komunita ráda mluví o „časových limitech“ [deadline] a na ně orientovaném plánování. V tomto článku se podíváme na plánovač podle časového limitu [deadline scheduler], který byl nedávno zaslán k revizím, a s ním spojenou diskuzi na nedávném Real Time Linux Workshop v Drážďanech.
Plánování v reálném čase má výhodu, že je plně deterministické – úloha o nejvyšší prioritě vždy běží. Plánování založené na prioritách má nicméně nějaké nepříjemné možnosti selhání (například inverzi priority a vyhladovění), ve skutečnosti zcela neizoluje úlohy běžící na stejném systému a často to není nejlepší způsob, jak problém popsat. Většinu úloh lze lépe popsat v pojmech, jako je množství práce, kterou je nutné dokončit v určitém čase; snaha pracovat v těchto pojmech vedla v minulých letech k výzkumu v oblasti plánování založeném na časovém limitu.
Systém s časovými limity odstraňuje statické priority. Místo nich každá úloha poskytuje tři parametry pro plánování:
Časový limit [deadline] – kdy musí být práce dokončena
Periodu vykonávání [execution period] – jak často musí být práce prováděna
Dobu běhu v nejhorším případě [worst-case execution time, WCET] – maximální množství času CPU, které bude potřeba k tomu, aby se práce vykonala
Úlohy plánované podle časového limitu se obvykle pravidelně opakují – k tomu je parametr perioda – ale s tímto modelem lze obsluhovat i práci, která se objevuje sporadicky.
Tento model má několik výhod. Lze snadno spočítat vyžadovanou „propustnost“ procesu – jak velké procento času CPU proces potřebuje – takže plánovač hned ze začátku ví, jestli je systém přetížen, nebo ne. Plánovač může (a měl by) odmítnout přijmout úlohu, která by vyžadovala větší propustnost, než je k dispozici. Odmítnutím práce navíc bude plánovač vždy schopen každému procesu poskytnout požadovaný čas CPU do specifikovaného limitu. Tento slib vývojáře běhu v reálném čase potěší.
Linux v současnosti žádný takový plánovač nemá. Dario Faggoli a další nicméně zaslali implementaci k revizím; Dario také tento plánovač v Drážďanech představil. Tato implementace používá algoritmus „nejprve nejbližší limit“ [earliest deadline first, EDF], 
který je založen na jednoduchém konceptu: Proces, jehož časový limit vyprší nejdřív, poběží první. EDF se v podstatě pokouší zajistit, že každý proces začne běžet do svého limitu, nikoliv že do té doby stihne svou práci. Vzhledem k tomu, že EDF spustí práci tak brzy, jak je to možné, by však většina úloh měla s rezervou doběhnout před svým limitem.
Tento plánovač je implementován vytvořením nové plánovací třídy nazvané SCHED_EDF. Odstraňuje rozdíly mezi parametry „časový limit“ a „perioda“, pro oba používá jediný čas. Patch tuto třídu vkládá mezi existující třídy pro běh v reálném čase (SCHED_FIFO a SCHED_RR) a běžnou interaktivní plánovací třídu (SCHED_FAIR). Toto umístění motivuje snaha neporušit slib, že „úloha o nejvyšší prioritě vždy běží“, který poskytují POSIXové třídy pro běh v reálném čase. Peter Zijlstra si ale myslí, že plánování v časovém limitu by mělo běžet s nejvyšší prioritou; jinak nebude moci zajistit, že se podaří vejít se do limitů. Toto umístění by znamenalo porušení POSIXových požadavků, na což ale Peter reaguje: Stručně – k čertu s POSIX.
Peter by také byl rád, kdyby se plánovač jmenoval SCHED_DEADLINE, protože EDF není jediný existující algoritmus pro plánování s časovým limitem. V budoucnu může být potřeba použít jiný algoritmus, aniž by byly aplikace nuceny měnit to, kterou plánovací třídu požadují. V současnosti se jediným možným soupeřem zdá být plánování „nejprve nejmenší rezerva“ [least laxity first, LLF], které vybírá tu úlohu, která má nejkratší interval mezi plánovaným dokončením a časovým limitem. LLF se snaží zajistit, že každý proces dokončí výpočet do svého časového limitu. Oproti EDF ale častěji dochází k přepínání kontextu a v současnosti takový plánovač nikdo do Linuxu netlačí.
Jedna hezká vlastnost plánování podle časového limitu je to, že by žádný proces neměl být schopen zabránit jinému procesu dokončit práci předtím, než vyprší jeho limit. Jak uvidíme níže, skutečný svět je trochu horší, ale i kdyby se neobjevily větší problémy, může plánovač tuto garanci poskytnout jenom v případě, že každý proces doběhne v čase deklarovaném WCET. Plánovač EDF tento problém řeší poměrně násilnou cestou: Když proces překročí svou propustnost, je jednoduše z CPU odstraněn, dokud nezačne další perioda časových limitů. Tento přístup je jednoduché implementovat a zajišťuje to, že limity budou dodržovány, ale může to být nepřívětivé k procesu, který příležitostně potřebuje dělat nějaké počítání navíc.
V patchi SCHED_EDF procesy indikují konec periody zpracovávání voláním sched_yield(). Tato modifikace sémantiky tohoto systémového volání se však některým vývojářům nelíbí; je pravděpodobné, že finální patch bude dělat něco jiného. Možná bude za tímto účelem vytvořeno nové systémové volání „Prozatím mám hotovo“.
Peter v Drážďanech mluvil také; jeho projev se týkal hlavně toho, proč Linux ještě plánovač orientovaný na časový limit nemá. Problém „co se stane, když proces překročí WCET“ udal jako jeden z důvodů. Výpočet nejhoršího případu doby běhu je pro jakýkoliv netriviální program příliš složitý. Jak to řekl Peter, někteří výzkumníci strávili celý život snahou to vyřešit. Někteří lidé pracují na tom, jak automaticky určit WCET ze zdrojového kódu, ale mají velmi daleko k tomu, aby byli schopni udělat to na reálných systémech. Prozatím tedy specifikace WCET znamená empirické pozorování a hádání.
Další problém EDF je ten, že na jednoprocesorovém systému pracuje lépe než na SMP systémech. Pravé EDF na multiprocesorovém systému vyžaduje spravovat globální frontu běhu se všemi problémy týkajícími se škálovatelnosti, které z toho vyplývají. Jedno řešení je rozdělit SMP systémy tak, že se z každého CPU v podstatě stane nezávislá plánovací doména; patch SCHED_EDF takto funguje. Rozdělené systémy nicméně mají vlastní problémy: Přiřazení úlohy k CPU může být problematické a je těžké (nebo nemožné) systém využít naplno, když se úlohy nemohou přesouvat mezi CPU.
Další problém s dělením je to, že některé problémy s plánováním jednoduše nelze vyřešit bez příležitostné migrace procesu. Představme si dvouprocesorový systém, na kterém běží tři procesy a každý vyžaduje 60 % času CPU. Systém zjevně má dost zdrojů na to, aby tyto tři procesy mohly běžet, ale ne v případě, že nemůže některý z nich přemístit z procesoru na procesor. Dělený plánovač EDF tedy potřebuje mít možnost občas procesy přesunout; vývojáři SCHED_EDF na této migrační logice pracují, ale zaslána ještě nebyla.
Další vážný problém je podle Petera inverze priorit. Techniky dědění priorit vyvinuté jako řešení inverze priorit jsou s nimi spojené; není jasné, jak je aplikovat na plánovače orientované na časový limit. Problém ale skutečně existuje: Představme si proces, který získá důležitý zámek ![[Peter Zijlstra]](http://lwn.net/images/conf/rtlws11/peter-zijlstra-sm.jpg)
a následně je přerušen preempcí nebo je mu CPU odňato, protože překročil WCET. Takový proces může blokovat spuštění jiného procesu, který by jinak běžet mohl a kterému možná již brzy vyprší lhůta.
Je několik způsobů, jak tuto záležitost řešit. Pravděpodobně nejjednodušší je dědění časového limitu: Vlastník zámku zdědí po dobu, po jakou bude zámek držet, nejbližší časový limit. Sofistikovanější je dědění propustnosti; v tomto případě vlastník zámku, který vyčerpal WCET, obdrží „dotaci“ času od procesu(ů), které jsou tímto zámkem blokovány. Varianta této techniky je zástupné vykonávání [proxy execution]: Blokované procesy zůstávají ve frontě běžících, ale když „běží“, jejich místo přejímá vlastník zámku. Zástupné vykonávání je v SMP prostředích záludné, když je několik procesů blokováno stejným zámkem; výsledkem by mohlo být to, že se několik CPU pokusí vykonávat stejný proces. Zdá se, že řešením tohoto problému je migrace blokovaného procesu na CPU vlastníka zámku.
Zástupné vykonávání také narazí na potíže, když je proces držící zámek blokován kvůli I/O. V takovém případě nemůže běžet jako zástupce původní blokové úlohy, kterou je tedy nutné z fronty odstranit. To následně vynucuje vytvoření „pořadníku“ čekajících procesů, které je nutné vrátit do stavu „spustitelné“, když se do tohoto stavu přepne jiný proces (vlastník zámku). Není potřeba říkat, že tato logika zvyšuje složitost a režii systému.
Poslední problém je podle Petera POSIX, ale ten je jednoduché vyřešit. Vzhledem k tomu, že POSIX na téma plánování podle časového limitu mlčí, můžeme si dělat, co chceme, a vše bude v pořádku. Zopakoval, že SCHED_DEADLINE bude, co se priority týče, pravděpodobně umístěno nad SCHED_FIFO. Objeví se nové systémové volání – sched_setscheduler_ex() – které procesům umožní vyžadovat plánování podle časového limitu a odpovídajícím způsobem nastavit parametry; patch SCHED_EDF toto volání implementuje. Pro plánování podle časového limitu je již v Linuxu mnoho dílů přítomno, ale ještě zbývá vyřešit mnoho detailů.
Shrnutí: Plánování podle časového limitu je ve skutečném světě netriviální problém – což ve skutečném světě platí pro plánování obecně. Tyto problémy by nicméně měly být řešitelné a Linux by někdy v budoucnu měl být schopen deadline plánovač podporovat. Takový plánovač se přirozeně objeví nejprve ve stromě pro běh v reálném čase, ale nakonec by si mohl najít uživatele i mimo tuto komunitu. Plánovače s časovým limitem jsou přirozené pro periodické úlohy, jako je správa multimediálních proudů, kde by mohly eliminovat problémy s nerovnoměrností [jitter] a zahozenými daty. To je ale hudba budoucnosti; aby bylo možné kód široce využívat, musí na to být připraven. A to je, jak všichni víme, proces, který uznává jenom pár časových limitů.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
buff = (int *) malloc (INT_SIZE * buff_size); if (! buff) return;
12.11.2009 19:01
Stanislav Brabec | skóre: 45
| Praha
buff = (int(*)[buff_size]) malloc (INT_SIZE * buff_size); if (! buff) return;Podle mně je tento zápis o něco korektnější, protože dává kompilátoru přesnější informaci.
To omezuje přidávání pravidel na ty, kdo se vyznají v jaderném kódu a zároveň jsou schopni pracovat v prostředí Java/XML.Chtel bych videt jaderneho programatora, ktery neni schopen editovat XML.
Ještě bych ho doplnil omáčkou co byla okolo, která také stojí za to:
What the ^&@* is wrong with "enterprise SCSI" people? The amount of crazy is overwhelming.A třešnička na konec
The whole crazy "high end SCSI" industry needs a f*cking exorcism.
Stroje od Dellu jsou navrženy tak, aby ve většině případů načítaly síťová rozhraní ve stejném pořadí.No, to určitě. Můj notebook Dell Inspiron má snad po každým rebootu přehozenou ethernetovku a wifinu na eth1 a eth0.
Můj notebook Dell Inspiron má snad po každým rebootu přehozenou ethernetovku a wifinu na eth1 a eth0.Takže mají ve většině případů stejné pořadí? To je ale přesně to, co dotyčný tvrdil.
12.11.2009 22:50
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
12.11.2009 23:38
14.11.2009 00:21