abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
19.4. 01:01 | Zajímavý článek
Společnost Coverity vydala Coverity Scan Open Source Report za rok 2013. Dle nejnovější zprávy je například v open-source C/C++ projektech průměrně 0,59 chyby na 1000 řádků kódu, kdežto u proprietárních projektů je to 0,79 chyby na 1000 řádků kódu. Službu Coverity Scan využívá více než 1700 open-source projektů.
Ladislav Hagara | Komentářů: 10
18.4. 01:23 | Komunita
ISC (Internet Systems Consortium) vydalo verzi 1.2.0 DNS serveru BIND 10. Současně bylo ale oznámeno, že se jedná o poslední verzi BIND 10. Projekt byl přejmenován na Bundy a předán komunitě. ISC bude nadále rozvíjet BIND 9 a ISC DHCP.
Ladislav Hagara | Komentářů: 14
17.4. 23:22 | Nová verze
Vyšlo Ubuntu 14.04 (Trusty Tahr) a jeho deriváty jako Kubuntu nebo Xubuntu. Jedná se o vydání s dlouhodobou podporou: pět let v případě Ubuntu Desktop/Server/Core/Kylin, Edubuntu a Kubuntu, tři roky jinak.
davkol | Komentářů: 42
17.4. 20:40 | Nová verze

V kontrolním skriptu byla vylepšena detekce Linux/Ebury a přidány nově zjištěné signatury napadených webových serverů komponentou Linux/Cdorked.

… více »
Leos | Komentářů: 0
17.4. 07:00 | Nová verze
Byla vydána verze 4.13 desktopového prostředí KDE. Nová verze přináší především vylepšení aplikací. Vlastní prostředí a knihovny jsou od vydání verze 4.11 (zprávička) v udržovacím módu. Vývojáři se primárně věnují přechodu na KDE Frameworks 5. Jedinou novinkou je vylepšené sémantické vyhledávání.
Ladislav Hagara | Komentářů: 28
17.4. 06:55 | Zajímavý článek
V listopadu loňského roku vyšel na stránkách Opensource.com úvod do SELinuxu plný obrázků (zprávička). Dan Walsh byl za něj oceněn v rámci 2014 Opensource.com Community Awards. Máirín Duffy, autorka obrázků použitých v článku, zveřejnila na svém blogu SELinux omalovánky vytvořené na základě článku. Omalovánky jsou k dispozici ve formátech PDF a SVG pod licencí CC BY-SA 4.0.
Ladislav Hagara | Komentářů: 12
17.4. 01:23 | Komunita
V San Francisku probíhá čtyřdenní konference Red Hat Summit 2014. Vybraná videa z konference, například přednáška prezidenta a CEO Red Hatu Jima Whitehursta, se začínají objevovat na YouTube kanálu Red Hat Summit.
Ladislav Hagara | Komentářů: 0
16.4. 23:52 | Zajímavý článek
Debian oznámil LTS podporu pro Debian 6.0 Squeeze. Za normálních okolností by jeho podpora skončila 31. května. LTS podpora bude pokračovat do února 2016, tedy pět let od jeho vydání. Pokud se tento model osvědčí, předpokládá se jeho využití i pro další vydání.
fish | Komentářů: 18
16.4. 10:11 | Komunita
OpenBSD 5.5 vyjde 1. května. Oficiální píseň je už ale k dispozici. Nejnovější hudební hit z produkce OpenBSD je věnován problému roku 2038: Řekněte mi doktore, jaký bude rok, 1901 nebo 2038? OpenBSD 5.5 přijde s 64bitovým time_t na všech platformách. Píseň s názvem Wrap in Time lze stáhnout ve formátech MP3 a OGG.
Ladislav Hagara | Komentářů: 52
15.4. 23:38 | Pozvánky
LvB a Openmobility vás zvou na 103. sraz příznivců svobodného SW a HW, který se bude konat v pátek 18. dubna od 18 hodin v restauraci Magistr na ulici Hrnčířská 23. Těšíme se na vás.
Ladislav Nešněra | Komentářů: 22
Máte na svém notebooku zašifrovaný pevný disk?
 (79%)
 (21%)
Celkem 722 hlasů
 Komentářů: 22, poslední včera 20:15
Rozcestník
Reklama
Autoškola testy online Levný benzín

Jaderné noviny – 27. 10. 2011: Realtime minisummit v Praze

7. 11. 2011 | Luboš Doležel | Jaderné noviny | 2887×

Aktuální verze jádra: 3.1. Citáty týdne: Linus Torvalds, Neil Brown. Realtime minisummit 2011: Per-CPU data; Softwarová přerušení; Přesun do upstreamu; Budoucnost.

Obsah

Aktuální verze jádra: 3.1

link

Vyšlo jádro 3.1, a to Linusovo rukou dne 24. října. Hlavními funkcemi v tomto tak trochu opožděném vydání zahrnují vylepšenou správu paměti Xenu, vylepšení sledování procesů (příkaz PTRACE_SEIZE), rozšíření lseek() pro snazší hledání děr v souborech, podpora architektury OpenRISC a ještě více.

V době psaní tohoto textu bylo do hlavní řady přetaženo nějakých 4400 patchů pro verzi 3.2. Mezi stromy, které byly zatím přetaženy, patří síťování, USB, staging a bezpečnost; úplné shrnutí začleňovacího okna se objeví v příštích Jaderných novinách.

Stabilní vydání: 25. října vyšlo jádro 3.0.8 s obvyklou hromadou důležitých oprav.

Citáty týdne: Linus Torvalds, Neil Brown

link

Z čeho mám větší obavy než z jaderného summitu, je to, že vývojový cyklus verze 3.1 se příliš protáhl, takže mám trochu obavy, že začleňovací okno 3.2 bude chaotičtější než obvykle, protože se bude začleňovat víc věcí. Ale to s problémy KS nesouvisí a mám také za to, že extra čas na vývoj byl do značné míry vyrušen ztrátou produktivity kvůli výpadku k.org.

-- Linus Torvalds

Neměl jsem v plánu to udělat... ale pak jsem to udělal. Myslím si, že kódování je někdy trochu jako čokoláda.

-- Neil Brown

Realtime minisummit 2011

link

Minisummit realtime Linuxu proběhl 22. října v Praze během třetího dne 13. Realtime Linux Workshopu. Součástí letošního shromáždění byla relativně nestrukturovaná diskuze, která se nedá moc čistě sepsat. Pokusili jsme se zde shrnout nejdůležitější témata, doplněná o materiály z některých přednášek.

Per-CPU data

link

Jednou z největších výzev pro sadu patchů pro realtime preempci bylo už od začátku zacházení s per-CPU daty. Vývojáři orientovaní na propustnost mají per-CPU proměnné v oblibě; usnadňují přístup k datům bez zámků a zlepšují škálovatelnost kódu. Ale práce s per-CPU daty obvykle vyžaduje vypnutí preempce, což je přímo proti tomu, o co se snaží sada patchů realtime preempce. Je to klasická ukázka toho, jak mohou být vysoká propustnost a nízká latence protichůdnými cíli.

Realtime patch tradičně řešil per-CPU data tak, že na ně dal zámek a pracoval s nimi jako s každým jiným sdíleným prostředkem. API get_cpu_var() tento režim podporuje docela dobře. Nedávno toto API ale bylo odstrčeno novou sadou funkcí s názvy jako this_cpu_read() a this_cpu_write(). Předností těchto funkcí je rychlost, zejména na architektuře x86, kde většina operací znamená jen jedinou instrukci. Ale toto nové API způsobilo jisté obtíže, obzvláště (ale ne výhradně) pro lidi z realtime party.

Prvním problémem je to, že toto API nemá žádný vestavěný mechanismus zamykání; dokonce ani nezakazuje preempci. Takže hodnota vrácená z this_cpu_read nemusí odpovídat CPU, na kterém volající vlákno běží v době, kdy něco dělá s hodnotou, kterou čte. Bez nějakého vnějšího zákazu preempce může sled this_cpu_read() následovaného this_cpu_write zapsat zpátky hodnotu na jiném CPU, než kde byla hodnota přečtena, což poškodí výslednou strukturu dat; tento typ problému byl už párkrát zaznamenán.

Větším problém je ale to, že toto API žádným způsobem neindikuje, kde se v kódu nachází kritická sekce týkající se per-CPU dat. Takže není žádný způsob, jak přidat extra ochranu pro realtime operace a není žádný způsob, jak přidat nějakou infrastrukturu pro ladění, aby se ověřilo, že je API používáno korektně. Na mailing listu se kolem těchto funkcí objevily dosti ostré diskuze, ale jednoduchým argumentem je to, že věci urychlují, takže se proti nim těžko argumentuje. API this_cpu představuje skutečný přínos; Ingo Molnar poznamenal, že API jako takové není problémem – je to jen nekompletní řešení.

Ať už je nebo není nekompletní, počet míst, odkud se toto API volá, s každým vydáním jádra roste o stovky, takže je třeba s tím něco udělat. Mnoho času bylo stráveno diskutováním o tom, jak tyto funkce pojmenovat, protože je to takto matoucí. Co „toto CPU – this CPU“ znamená v situaci, kdy může volající vlákno být kdykoliv přemigrováno? Může se objevit snaha změnit tato jména, aby se tím odrazovalo od nesprávného užití API, ale to jednoznačně není dlouhodobé řešení.

Prvním krokem může být přidat do rozhraní nějakou instrumentaci, která by dokázala najít chybné užívání. Když už nic jiného, tak alespoň skutečný důkaz přítomnosti chyb ospravedlní změny, které bude potřeba udělat. Hovořilo se o vytvoření „lokálního zámku“, který by byl použit k ohraničení per-CPU kritických sekcí, zakázání migrace (a pravděpodobně preempce) v těchto sekcí a na realtime k prostému uzamčení. Takové rozhraní by, snad kromě splnění cílů všech lidí, umožnilo za pomoci kontroloru zámků ověřit, zda jsou per-CPU data správně užívána.

Vývojáři realtime mezitím nedávno přišli s novým obecným přístupem ke správě per-CPU dat. Namísto zakazování preempce během práce s takovými daty prostě jen zakážou migraci mezi procesory. Pokud (a toto je takové větší „pokud“) jsou per-CPU data korektně chráněna zámkem, zákaz migrace by měl postačit k tomu, aby si procesy přestaly lézt do zelí, zatímco by se zachovala možnost toho, aby procesy s vysokou prioritou přerušily [preempt] procesy s nižší prioritou, když to bude třeba.

Ze zákazu migrace pramení obavy, že by se procesy mohly zaseknout a došlo by k dlouhým latencím, i když by byla k dispozici volná CPU. Pokud proces s nízkou prioritou zakáže migraci a pak dojde k preempci, nemůže být přesunut na volný procesor. Takže tento proces by prostě čekal, dokud nedokončí proces, který jej přerušil, nebo dokud nebude sám přemigrován. Pracovalo se na vystižení tohoto problému; Paul McKenney chvíli hovořil o práci, kterou v této oblasti odvedl. V současnosti není jasné, o jak velký problém doopravdy jde, ale někteří vývojáři mají skutečně obavy, jaký vliv může tato technika mít na některou zátěž.

Softwarová přerušení

link

Už dlouhou dobu sada realtime patchů oddělovala obsluhu softwarových přerušení („softirq“) do odděleného vlákna, což jej učinilo přerušitelným [preemptable] jako všechno ostatní. Nedávné patche toto oddělení ale odstranily, a to z několika důvodů: aby patche byly blíže hlavní řadě a aby nedocházelo k brzdění zpracování síťových věcí. Pohyb dat v síťové vrstvě značně závisí na softirq; přesunutí této práce do odděleného vlákna může přidat latenci na nežádoucím místě. Ale pro počáteční oddělení byl dobrý důvod: softwarová přerušení mohou sama o sobě způsobovat latenci. Proto se hovořilo o tom, že by se oddělení částečně vrátilo. Většina softirq by mohla běžet v odděleném vlákně, ale síťová softirq by možná mohla nadále běžet jako „pravá“ softwarová přerušení. To není řešení, které by všechny potěšilo, ale krátkodobě by to věci zlepšilo.

Vypadá to, že na dlouhodobém řešení se lidé shodnou: softwarová přerušení prostě musí kompletně zmizet. Softirq mohou být povětšinou nahrazena vlákennou obsluhou přerušení [threaded interrupt handlers]; a jak to Thomas Gleixner popsal, API ovladačů NPAPI v síťové vrstvě je ve skutečnosti jen levná náhražka obsluhy IRQ ve vláknech. Diskutuje se o přesunutí vlákenné obsluhy i v subsystému úložišť; to zjevně představuje naději, že se zjednoduší komplexní kód obnovy po chybě v SCSI. Nicméně nejde o triviální změnu ani v úložištích, ani v síťování; než se to udělá, dlouho to potrvá. Mezitím se do realtime patchů asi vrátí částečně odloučená obsluha softirq.

Zajímavým problémem spojeným s obsluhou softirq je četný výskyt operací „trylock“. Existuje řada míst, kde se kód pokusí získat zámek; pokud tento pokus selže, obsluha IRQ se zastaví s představou, že se to zkusí znovu při příštím běhu softirq. Pokud ale obsluha běží jako vlákno, je zde velká šance, že půjde o vlákno s nejvyšší prioritou, takže to bude spuštěno znovu okamžitě. Obsluha softirq zacyklená tímto způsobem může zabránit naplánování vlákna, které drží kýžený zámek, což vede k livelocku. Tento problém už byl několikrát zpozorován na skutečných systémech; pro opravu může být nutné restrukturovat dotčený kód.

Přesun do upstreamu

link

Proběhla dlouhá debata o tom, jak vývojáři realtime plánují dostat většinu nebo celý patch do upstreamu. Je totiž mimo strom docela dlouho – původní patch preempt-rt byl ohlášen téměř přesně před sedmi lety. Během té doby se velké objemy kódu přesunuly z realtime stromu do hlavní řady, ale stále je tu nějakých 300 patchů, jež jsou nadále mimo hlavní řadu. Thomas už několikrát podotkl, že tyto patche spravuje už dost dlouho a nechce, ani neplánuje to dělat navždy.

Většina z toho, co je v realtime stromu, vypadá, že by se do upstreamu dostat mohla, jen by snad bylo potřeba trochu pročištění. Nyní je ve frontě kolem 75 patchů, které směřují do začleňovacího okna 3.2 a ještě více by se toho mohlo připravit pro 3.3 nebo 3.4. Aktuálním cílem je během této doby začlenit co nejvíc kódu, to by mohlo značně omezit velikost realtime sady patchů, což by usnadnilo údržbu.

Je tu několik problémových oblastí. Získávání náhodnosti je v realtime stromu zakázáno; naplňování zdroje entropie totiž způsobuje nežádoucí latenci. Vypadá to, že přispívání entropií v jádře upadá; není jisté, jestli je údržba softwarového zdroje účelná, když se v procesorech objevují hardwarové generátory entropie. Je stále řada míst, kde jsou přerušení zakázaná, pravděpodobně to není potřeba; oprava tohoto si vyžádá auditování kódu a pochopení, proč jsou přerušení vůbec zakazována. Relayfs má problémy samo o sobě, ale má to jen jednoho uživatele ve stromu; prozatím by to asi jen bylo zakázáno pro realtime. Rozhraní stop_machine() je vnímáno jako problémové a po většinu času asi jako zbytečné.

A tak dále. Řada účastníků odešla z tohoto sezení se seznamem patchů k opravě a zaslání do upstreamu; s trochou štěstí se velikost realtime patche mimo jádro znatelně zmenší.

Budoucnost

link

Jakmile bude současný realtime patch začleněn, bude práce hotová? V minulosti bylo zmenšování patche těžké kvůli tomu, že vývojáři neustále přicházeli s novými věcmi. Nyní to však vypadá, že na horizontu není mnoho novinek. V blízké budoucnosti se očekává jen několik významných přídavků:

  • Deadline plánování. Tento patch je ve stavu, který „není až tak špatný“, ale pozornost vývojáře byla odvedena k novým věcem. Vypadá to, že práce na deadline plánovači může být převzata novým vývojářem a práce budou pokračovat.
  • Izolace CPU – schopnost běžet na jednom nebo více procesorech bez tikání hodin nebo jiné režie. Fredéric Weisbecker pokračuje v práci na těchto patchích, ale zbývá hodně práce a není to až tak urgentní, aby byly hned začleněny. Toto je vnímáno jako dlouhodobý projekt.

Kdysi dávno bylo zavedení deterministické odezvy do obecného operačního systému vnímáno jako nemožný účel: výsledné jádro by nikomu nefungovalo správně. Nicméně zatímco někteří lidé říkali, že vývojáři pracující na realtime preempci prostě ještě musí zapracovat, už tohoto cíle povětšinou dosáhli. Práce na realtime nemusí být nikdy „hotová“ – stejně jako linuxové jádro jako celek není nikdy hotové – ale tento projekt vypadá, že dosáhl většiny svých cílů. Váš redaktor se ponaučil, aby nedělal předpovědi, kdy bude všechno začleněno; postačí říct, že vývojáři sami vypadají odhodlaně k tomu, aby to bylo hotové spíš dřív než později. Takže i když tu s námi možná vždycky bude realtime sada patchů mimo strom, je tu šance, že se v příštích vývojových cyklech značně zcvrkne.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

7.11.2011 07:22 whata
Rozbalit Rozbalit vše this_cpu
Hm, docela zajímavá komplikace.

Možná by stačilo něco ala load/store exclusive jako mají některé RISC procesory.

cpu_read by označil current_thread značkou a cpu_write by si značku zkontroloval, suspend threadu by značku vypínal, případně v samotném cpu_write posunul kontext. "Aplikační" část by si pak musela hlídat, zda se write povedl a případně celý read/write opakovat, což je sice trochu komplikace, ale pořád v rámci spolehlivosti asi použitelnější než přístup zcela bez kontroly.
ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.