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 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
22.9. 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 91
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 8
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 11
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 6
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 2
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (24%)
 (3%)
 (0%)
Celkem 402 hlasů
 Komentářů: 34, poslední dnes 12:54
Rozcestník

Jaderné noviny – 28. 9. 2017: Poznámky z mikrokonference o trasování na LPC

18. 10. 2017 | Redakce | Jaderné noviny | 2527×

Stav vydání jádra. Citát týdne: Daniel Vetter. Poznámky z mikrokonference o trasování na LPC.

Stav vydání jádra

Současné vývojové jádro je 4.14-rc2, vydané 24. září. Linus řekl: „Nic nevyčnívá, ačkoliv snad jsme se dostali přes všechny problémy s x86 ASID. Musím to zaklepat na dřevo.“

Stabilní aktualizace: za poslední týden nebyly žádné vydány. Verze 4.13.4, 4.9.52, 4.4.89 a 3.18.72 byly v době psaní tohoto článku v procesu revidování (a zpožděné).

Citát týdne

A ano, některé soubory se skoro nedají číst a ani zdaleka se neblíží standardům pro jaderný kód. Ale o tom to je, jsou v podstatě kázáním hardwarových inženýrů, které se shodou okolností dá analyzovat pomocí GCC.

Daniel Vetter dává zelenou AMD „Display Core“

Poznámky z mikrokonference o trasování na LPC

Notes from the LPC tracing microconference. Jonathan Corbet. 21. září 2017

Mikrokonference věnovaná trasování a BPF se konala poslední den Linux Plumbers Conference 2017. Pokrývala řadu témat zajímavých pro uživatele, kteří hodně využívají trasování jádra a uživatelského prostoru. Následuje shrnutí řady těchto diskuzí o tématech jako introspekce BPF, trasování zásobníku, kprobes, uprobes a Common Trace Format.

Bohužel musel autor článku konferenci opustit před jejím skončením, takže tento článek nepokrývá všechna témata, o kterých se diskutovalo. Pro zainteresované je tu instance Etherpadu, která obsahuje poznámky účastníků konference.

Introspekce BPF

Martin Lau zahájil své vystoupení konstatováním, že programy BPF obvykle používají pro komunikaci s jádrem nebo uživatelským prostorem mapy (maps). Pokud ale někoho zajímá, co vlastně v některé mapě je, má problém. Co se v mapě ukládá, jde odhalit nahlédnutím do zdrojového kódu programu BPF, jenže tento zdrojový kód nemusí být vždy dostupný. Co by si Lau představoval, je nějaký snadný způsob, jak hezky vypsat obsah mapy.

Jeho navrhovaným řešením je připojit ke každé mapě trochu metadat, která by obsahovala popis jednotlivých obsažených záznamů. Vypadalo by to jako definice struktury v C. Navrhovaným názvem takového popisu je „kompaktní formát typu C“ (compact C-type format, CTF), ale tento název se zcela jistě bude muset změnit v případě pokračujících prací, protože stejnou zkratku již používá Common Trace Format. Popis by byl vytvořen pomocným programem, a pak předán jádru skrze systémové volání bpf(), které vytvoří mapu. Jádro by ověřilo data a uložilo je, čímž by se později na vyžádání zpřístupnila.

Tenhle projekt se ale nemusí dostat daleko, protože se kolem něj vynořila spousta pochybností o tom, zda je opravdu potřeba. Pokud existují uživatelé, kteří opravdu potřebují samostatný popis obsahu mapy, mělo by být možné takové informace spravovat v uživatelském prostoru. Takže i když tento nápad nemusí být mrtvý, bude se v případě, že se na něm bude pokračovat, potýkat s nějakým odporem.

Trasování zásobníku a kprobes

Alexej Starovoitov mluvil o páru problémů, na které narazil Facebook. Oba jsou výsledkem masivního využívání trasování (tracing) ke sledování vlastních operací. Trasování většinou probíhá neustále a podrobná trasování konkrétních procesů je možné kdykoli povolit nebo zakázat, přičemž rozhodnutí je často provedeno uvnitř jádra. Podpory trasování v jádře byla navržena převážně ke sporadickému použití, takže když trasování probíhá nepřetržitě, ne všechno vždy funguje, jak má.

Jedním problémovým bodem je generování informací o zásobníku spojených se specifickými událostmi trasování. To zahrnuje převedení adresy, kde se událost stala, na symbolickou adresu. Pokud je adresa v jaderném prostoru, řekl Starovoitov, pak překlad většinou funguje, ale občas může narazit, pokud se načítají nebo odebírají moduly. Překlad adres uživatelského prostoru také většinou funguje, ale procesy mohou rychle přicházet a odcházet a může také docházet k rychlým změnám v rozložení adresních prostorů. To vede k situacím, kdy mapování potřebná k překladu již neexistují v okamžiku, kdy dojde k pokusu o překlad.

Navrhl tři možná řešení. „Ošklivý“ přístup spočívá v zaslání události do uživatelského prostoru, kdykoli je trasování zahájeno. Proces v uživatelském prostoru by poté pořídil snímek rozložení adresního prostoru cílů trasování. Takové řešení ale může vést k chybám souběhu, a tak není zcela spolehlivé.

Lepší (i když ne „hezkou“) alternativou by bylo přidat pomocnou funkci BPF, která by procházela adresním prostorem v reakci na události a házela informace o trasování zpět na zásobník BPF. Přidal by se nový typ mapy, který si pamatoval potřebné informace o rozložení pro uživatelský prostor, což by se hodilo, jakmile by došlo na generování symbolické stopy zásobníku. Tohle řešení by fungovalo, ale bylo by nákladné.

Nejlepším přístupem by bylo, kdyby jádro jednoduše přeložilo adresy do párů soubor-offset a generovalo trasy interně. Tento překlad se dá rychle zvládnout přímo v jádře, které má všechny důležité informace po ruce. Většina stop je relativně malá – tedy v případě, že na scénu nevstoupí Java. Peter Zijlstra dodal, že patche spekulativních výpadků stránek obsahují verzi find_vma(), která se obejde bez zámků a dokázala by vyhledávat ještě rychleji. Takže se zdá, že tohle bude opravdu nejlepší řešení.

Ten druhý problém se týká kprobes – dynamických trasovacích bodů vložených do jádra za běhu. Facebook intenzivně používá kprobes k řízení částí jádra, ke kterým není k dispozici vhodný trasovací bod. Problém podle Starovoitova je v tom, že kprobes jsou globálně spravované objekty a je to „celkem bída“. Většina potíží se týká textového rozhraní, které se používá k jejich správě.

Na nejvyšších příčkách seznamu stížností je skutečnost, že proces může vložit kprobes, pak neočekávaně skončit (nejspíš spadnutím). Tyto sondy nebudou automaticky uklizeny jádrem. Více procesů může vložit sondy na ta samá místa, což povede ke střetu jmen a komplikacím při úklidu po pádu. Pak jsou zde také přízemní problémy s použitím speciálních znaků v názvech sond.

Navržené řešení by spočívalo v rozšíření subsystému událostí perf (a zvláště systémového volání perf_event_open()) o schopnost vytvářet sondy kprobes. Ty by byly vázány k deskriptoru souboru vrácenému voláním perf_event_open() a v případě uzavření deskriptoru by se daly snadno uklidit. Nedocházelo by ke konfliktům jmen a kprobes by mohly mít libovolná jména.

K principu tohoto návrhu nebyly žádné námitky, ale panují obavy, že perf_event_open() je již příliš nabyté funkcemi. Takže Steve Rostedt navrhl, že by bylo lepší vytvořit pro tento účel nové systémové volání. Také by rád systémové volání pro povolování událostí ftrace. Nic z toho však neudělal – ze strachu, že by se pletl pod nohy vývojářské komunitě.

Další požadovanou funkcí jsou „odlehčené kprobes“, které by měly menší vliv na běhové prostředí. Nezpůsobovaly by vypínání přerušení a ukládaly by pouze podmnožinu registrů. Mluvilo se o různých nápadech, ale ani jeden zatím nemá ve formu kódu. Nějaké návrhy čekejte v nepříliš vzdálené budoucnosti.

Výkon uprobe

Uprobes jsou dynamické sondy umístěné do procesů v uživatelském prostoru. Jak poznamenal Yonghong Song, tyto sody mohou způsobovat problémy s výkonem. Sonda uprobe se implementuje jako trap v jádře, ale až sonda dokončí svou práci, je zapotřebí až třech trapů k obnovení stavu procesu, aniž by došlo k poškození aplikace. To činí uprobes příliš nákladnými na použití.

Různé trasovací systémy našly svá vlastní řešení, jak tento problém řešit. Například SystemTap používá ptrace() k zastavení procesu, který má být sondován, načež vloží instrukci skoku do obslužné funkce uživatelského prostoru, takže se jádru vyhne úplně. LTTng místo toho spoléhá na trasovací body vložené do zdrojového kódu a samostatné vlákno ke sdělení informací o trasovacích datech posluchači (listener). Ani jeden přístup není ideální, takže Song chtěl vědět, zda má někdo lepší nápad.

Zijlstra navrhl, aby se do kódu, kam by mohla být umístěna sonda, vložily instrukce no-op. Skutečná sondou by pak mohla být jednoduchá instrukce INT3, která nepotřebuje přemístit žádné stávající instrukce, tudíž nepotřebuje žádné trapy. Tento přístup však vyžaduje, aby vývojáři věděli, kam mohou být sondy umístěny.

Alternativou by bylo umístit skok přímo na jinou adresu v uživatelském prostoru, čímž by se dalo jádro obejít zcela. Uživatelé chtějí spouštět programy BPF z uprobes, ale není důvod, proč by to nemělo jít udělat z uživatelského prostoru. Možná, že co je opravdu zapotřebí, je mechanismus podporovaný jádrem, který by umožnil sledovacím systémům patchovat text programu v uživatelském prostoru. Mluvilo se o různých nápadech, který z nich se promění v kód, to se uvidí.

Ten druhý CTF

Matthieu Desnoyers poskytl rychlý přehled o Common Trace Format, což je specifikace reprezentace trasovacích dat. Existuje spousta trasovacích prvků, které mohou produkovat data v tomto formátu a několik nástrojů, které je mohou používat, včetně Trace Compass a LTTng Scope. Chybí zde však jeden spojující prvek, z ftrace chybí výstup do CTF. Jím navrhované řešení je vytvořit vstupní modul ftrace pro překladový nástroj Babeltrace.

Zijlstra se zeptal, k čemu je vlastně CTF dobrý. Když se dozvěděl, že se používá s grafickými nástroji na sledování, vtipkoval, že „pak jeho používání nemá smysl.“ Většina ostatních lidí v místnosti si myslela, že by takový překladač ale mohl být užitečný. Jedinou otázkou je, kdo by ho napsal. Rostedt řekl, že by se mu tahle funkce líbila, ale neměl čas na ní pracovat. Návrh, že by vstupní modul ftrace mohl být dobrým projektem pro Google Summer of Code, byl dobře přijat. To může být také přístup, jak příslušný software nakonec vznikne.

Nástroje BPF

Brendan Gregg energicky promluvil o nástrojích pro trasování s BPF. BPF Compiler Collection (BCC) nyní obsahuje zhruba sto jednotlivých nástrojů. Časem se stávají pokročilejšími a úže zaměřenými. Jeden z nich je například nástroj k měření soupeření o pool MySQL. Zdá se jasné, že do BCC nepatří úplně všechny nástroje, nikdo tam nechce vidět skriptů tisíc. Možná, že je na čase přemýšlet o vytvoření nových specializovaných repozitářů pro tyto skripty.

Také mluvil o zájmu o vysokoúrovňovější rozhraní pro sledovací funkce BPF. K tomu směřoval projekt Ply, ale zdá se, že se zastavil. Nedávno se nějaká práce věnovala bpftrace, ale možná, že bychom mohli udělat něco lepšího. Tohle by podle Brendana byla dobrá šance pro nějakého „nerda přes jazyky“, aby přišel s lepším způsobem popisování trasovacích úkolů. Žádný nerd se ale během sezení nepřihlásil.

(Autor by rád poděkoval Linux Foundation za podporu cesty na LPC 2017.)

       

Hodnocení: 75 %

        š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ář

18.10.2017 02:14 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny – 28. 9. 2017: Poznámky z mikrokonference o trasování na LPC
A ano, některé soubory se skoro nedají číst a ani zdaleka se neblíží standardům pro jaderný kód. Ale o tom to je, jsou v podstatě kázáním hardwarových inženýrů, které se shodou okolností dá analyzovat pomocí GCC.
By mohli rovnou vkládat HDL a linux by na to automaticky vygeneroval driver ;-).
Petr Tomášek avatar 19.10.2017 09:47 Petr Tomášek | skóre: 37 | blog: Vejšplechty
Rozbalit Rozbalit vše LPC
To LPC jako má znamenat „low-pin-count“, „licensed-professional-counseler“ nebo „landmarks preservation commission“?
multicult.fm | monokultura je zlo | welcome refugees!
19.10.2017 10:58 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: LPC
Ti, kdo nečtou jen nadpisy, najdou zkratku rozepsanou hned v první větě příslušné sekce.
20.10.2017 01:47 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: LPC
+1, i když teda v bakalářce do mě prali, že má být zkratka vysvětlená v prvním výskytu.
Fluttershy, yay! avatar 20.10.2017 10:49 Fluttershy, yay! | skóre: 83 | blog:
Rozbalit Rozbalit vše Re: LPC
Takže v nadpisu?
20.10.2017 15:05 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: LPC
Myslím že jsem ve sporných případech tu zkratku nakonec radši rozepsal :-D.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.