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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 18:18 | Nová verze

Byla vydána verze 5.0 frameworku pro vývoj webových aplikací Ruby on Rails (Wikipedie). Podrobnosti v poznámkách k vydání. Představení nových vlastností na YouTube.

Ladislav Hagara | Komentářů: 0
včera 17:18 | Bezpečnostní upozornění

Služba StartEncrypt od certifikační autority StartCom (konkurence Let's Encrypt) umožňovala komukoliv automaticky vydat certifikát k prakticky libovolné doméně (včetně domén jako Google, PayPal a Dropbox). Chyba (ve skutečnosti celá řada amatérských chyb) by měla být již opravena.

xm | Komentářů: 10
včera 17:17 | Nová verze

Byla vydána verze 2.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Z novinek lze zmínit například vylepšení podpory Xenu a OpenVZ.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Zajímavý software

V březnu bylo oznámeno, že v létě bude vydána první alfa verze webového prohlížeče s renderovacím jádrem Servo. Včera byla oznámená (en) noční sestavení pro OS X a Linux. Ukázka na YouTube.

Ladislav Hagara | Komentářů: 2
30.6. 23:45 | Nová verze

Byla vydána verze 3.00 open source programu pro prolamování hesel hashcat. Přehled novinek v příspěvku v diskusním fóru. Programy hashcat a oclHashcat (hashcat využívající grafickou kartu pomocí OpenCL) byly sloučeny do hashcat. Porovnání rychlostí verzí 2.01 a 3.00 v tabulce na Tabulky Google.

Ladislav Hagara | Komentářů: 0
30.6. 19:15 | Nová verze

Po sedmi měsících od vydání verze 0.20.0 (zprávička) byla vydána nová stabilní verze 0.21.0 desktopového prostředí Enlightenment. Z novinek lze zmínit lepší podporu Waylandu nebo možnost přehrávání videa na ploše. Podrobnosti v souboru NEWS.

Ladislav Hagara | Komentářů: 11
30.6. 14:41 | Nová verze

Byl vydán Linux Mint 18 s kódovým jménem Sarah. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu 18 s prostředím MATE a druhé o vydání Linux Mintu 18 s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 6
30.6. 07:00 | Zajímavý software

Na blogu věnovanému webového prohlížeči Chromium bylo oznámeno, že zdrojové kódy knihovny SwiftShader (Google Git) umožňující s vysokým výkonem renderovat 3D grafiku na CPU byly uvolněny pod open source licencí Apache 2.0. Knihovna SwiftShader je již od roku 2009 používána v prohlížeči Chrome pro renderování WebGL na počítačích se slabou grafickou kartou. U zrodu knihovny stála společnost TransGaming (pdf).

Ladislav Hagara | Komentářů: 0
29.6. 20:40 | Humor

Mozilla na svém blogu představila Codemoji, možnost jednoduchého šifrování zpráv pomocí Emoji. Cílem Codemoji je seznámit uživatele se základy šifrování.

Ladislav Hagara | Komentářů: 5
29.6. 20:00 | Zajímavý software

Jason A. Donenfeld oznámil v diskusním listu LKML (Linux Kernel Mailing List) vydání WireGuardu, open source softwaru pro vytváření VPN tunelů na Linuxu. Dle oznámení se jedná o řešení rychlejší, jednodušší, štíhlejší a užitečnější než IPsec a mnohem výkonnější než OpenVPN. Jaderný kód je podle Grega Kroah-Hartmana v pořádku.

Ladislav Hagara | Komentářů: 0
Jaký poměr stran pracovní plochy (příp. složené z více monitorů) preferujete?
 (7%)
 (13%)
 (52%)
 (20%)
 (4%)
 (2%)
 (1%)
Celkem 542 hlasů
 Komentářů: 32, poslední 28.6. 23:06
    Rozcestník
    Reklama

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

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

    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  
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.