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

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

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.)

       

Komentáře

[pc2005]

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]

To LPC jako má znamenat „low-pin-count“, „licensed-professional-counseler“ nebo „landmarks preservation commission“?

[Michal Kubeček]

Ti, kdo nečtou jen nadpisy, najdou zkratku rozepsanou hned v první větě příslušné sekce.

[pc2005]

+1, i když teda v bakalářce do mě prali, že má být zkratka vysvětlená v prvním výskytu.

[|🇵🇸]

Takže v nadpisu?

[pc2005]

Myslím že jsem ve sporných případech tu zkratku nakonec radši rozepsal .