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í
×
včera 02:09 | Komunita
V listopadu přešla Wikimedia z Bugzilly na Phabricator. K migraci se v příspěvku na svém blogu vrací André Klapper. Bugzilla byla používána 10 let. Vloženo bylo 73681 oznámení. Registrováno bylo přibližně 20000 uživatelských účtů. Porovnání Bugzilly s Phabricatorem na stránkách MediaWiki.
Ladislav Hagara | Komentářů: 21
18.12. 23:04 | Zajímavý software

Dnes vyšla na Steamu linuxová verze počítačové hry. Civilization: Beyond Earth Stalo se tak necelé dva měsíce po vydání Windows verze.Díky vánoční slevové akci lze hru na Steamu do zítřejších 19 hodin koupit s 40% slevou.

menphis | Komentářů: 10
18.12. 23:03 | Pozvánky
7. a 8.3.2015 proběhne na pražském Strahově další InstallFest. Můžete posílat náměty na přednášky nebo si rovnou svoji přednášku či svůj workshop přihlásit.
Jendа | Komentářů: 0
18.12. 23:02 | Nová verze
Laboratoře CZ.NIC vydaly ostrou verzi desktopové aplikace Datovka nesoucí označení 4. Tato verze plně nahrazuje starší Datovku 3.1 napsanou v jazyce Python. Podrobnější popis Datovky 4 a informace o rozdílech a vylepšeních naleznete na stránkách projektu nebo na blogu CZ.NIC. … více »
Vilem Sladek | Komentářů: 11
18.12. 18:00 | Nová verze
Byl vydán PostgreSQL 9.4. Nejnovější verze tohoto relačního databázového systému s otevřeným zdrojovým kódem přináší celou řadu nových vlastností a vylepšení. Zdůraznit lze například podporu nového datového typu JSONB. Podrobnosti v poznámkách k vydání.
Ladislav Hagara | Komentářů: 0
18.12. 02:30 | Nová verze
Byla vydána verze 14.12.0 KDE Aplikací (KDE Applications). Většina z nich je založena na knihovnách KDE Platform 4. Některé, například Kate, KWrite nebo Konsole, jsou už ale založené na KDE Frameworks 5. Podrobnosti v kompletním seznamu změn a na stránce s dalšími informacemi. Před několika dny vyšly také knihovny KDE Frameworks 5.5.0 a prostředí KDE Plasma 5.1.2.
Ladislav Hagara | Komentářů: 23
18.12. 02:30 | Bezpečnostní upozornění
Organizace ICANN se stala terčem spear phishingového útoku, při kterém útočníci získali přístup do několika zaměstnaneckých e-mailů. Následně získali administrátorský přístup také do aplikace "Centralized Zone Data System". Z tohoto důvodu byla hesla na účtech uživatelů CZDS deaktivována a uživatelé si musí požádat o reset hesla. Zároveň se uživatelům doporučuje provést změnu hesla i v dalších systémech, pokud někde používali stejné přihlašovací údaje. [CSIRT.CZ]
Ladislav Hagara | Komentářů: 8
17.12. 15:00 | Nová verze
Po ipfwadm, ipchains a iptables přichází nftables. Subsystém pro filtrování paketů nftables se v lednu dostal do Linuxu 3.13 (zprávička). Včera vyšla verze 0.4 balíku nftables. Nejnovější verze nftables a nástroje nft přináší například podporu Linuxu 3.18 a 3.19.
Ladislav Hagara | Komentářů: 0
17.12. 13:00 | IT novinky
Google na Google+ oznámil, že jeho Dokumenty, Tabulky a Prezentace nově otevřou také soubory ve třech hlavních ODF formátech (.odt, .ods a .odp).
Ladislav Hagara | Komentářů: 3
17.12. 11:30 | Zajímavý článek
Na serveru Hack A Day byl publikován článek o domácích počítačích za železnou oponou (Home Computers Behind The Iron Curtain). Martin Malý se zde věnuje počítačům jako JPR-1, Ondra, PMD 85, IQ 151 nebo Didaktik Gama.
Ladislav Hagara | Komentářů: 49
Disketu jsem naposledy použil během
 (46%)
 (3%)
 (11%)
 (37%)
 (2%)
Celkem 1601 hlasů
 Komentářů: 54, poslední 9.12. 17:16
    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 | 2956×

    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.