Jaderné noviny – 1. 7. 2009

28. 7. 2009 | Jirka Bourek | Jaderné noviny | 3281×

Aktuální verze jádra: 2.6.31-rc1. Citáty týdne: Neil Brown, Linus Torvalds, Andrew Tridgell, Dave Phillips. V krátkosti: O_NODE; O_PONÍCI; Patenty na VFAT; Cesta cestovatele. Čítače výkonnosti přidány do hlavní řady. API fanotify.

Obsah

• Aktuální verze jádra: 2.6.31-rc1
• Citáty týdne: Neil Brown, Linus Torvalds, Andrew Tridgell, Dave Phillips
• V krátkosti
  • O_NODE
  • O_PONÍCI
  • Patenty na VFAT
  • Cesta cestovatele
• Čítače výkonnosti přidány do hlavní řady
• API fanotify

Aktuální verze jádra: 2.6.31-rc1

Současné vývojové jádro 2.6 je 2.6.31-rc1 vydané 24. června. Začleňovací okno 2.6.31 je nyní zavřené a začala stabilizační fáze. Jako vždycky můžete detaily najít v kompletním changelogu.

Během minulého týdne nevyšly žádné aktualizace stabilních jader. Aktualizace 2.6.27.26, 2.6.29.6 a 2.6.30.1 jsou nyní nicméně revidovány, očekávané vydání je 3. července nebo později. Aktualizace 2.6.30.1 obsahuje přes 100 patchů.

Citáty týdne: Neil Brown, Linus Torvalds, Andrew Tridgell, Dave Phillips

Mám speciální směs cracku, která mi pomáhá vidět Vzory všude, dokonce i v C kódu. Některé vzory jsou zářivé, lesklé a elegantní, jiné jsou zablácené a matoucí. struct request_queue nad sebou právě nyní má zřetelný stín.

-- Neil Brown

Celá VM je navržena s předpokladem, že většina paměti jsou jenom čisté cache, a kolem tohoto předpokladu je navržena proto, že když to tak není, má VM tak málo svobody, že s tím stejně nemůže rozumně téměř nic dělat.

-- Linus Torvalds

Docela by mě překvapilo, kdyby se rozhodli změnit kód VFAT tak, aby Linux s tímto patchem přestal fungovat. Naopak bych řekl, že pravděpodobnější je, že jakmile se linuxové jádro s touto změnou rozšíří, Microsoft začne testovat své změny v souborovém systému VFAT, aby se ujistil, že fungují v Linuxu s tímto patchem.

-- Andrew Tridgell

Možná bychom měli chtít, aby jaderní vývojáři a správci hlavních distribucí všichni tři týdny používali Ardour a pokusili se alespoň o dvě vícestopé/vícekanálové nahrávky. Poté by snad možná získali lepší přehled o tom, co definuje systém pro vážně míněné nahrávání.

-- Dave Phillips

V krátkosti

O_NODE

Miklos Szeredi navrhl nový příznak (O_NODE), který by bylo možné předat voláním open(). Tento příznak by v podstatě říkal, že volající program chce otevřít předaný uzel souborového systému, ale ve skutečnosti s ním nechce nic dělat. Při takovém otvírání se nezavolá souborová operace open() na nižší úrovni, nebude povoleno čtení ani zápis atd.

Lze si položit otázku, k čemu je taková operace dobrá. Hlavní motivací se zdá být možnost vytvořit v aplikaci popisovač souboru, který lze přidat dalším systémovým voláním – řekněme fstat() nebo openat(). Popisovače souborů použité tímto způsobem v podstatě nepotřebují mít přístup k souboru, se kterým pracují, takže dává smysl poskytnout způsob, jak takové popisovače souborů vytvořit.

O_PONÍCI

Rik van Riel navrhl další nový příznak pro otevírání (ve skutečnosti nazvaný O_REWRITE), který má aplikacím pomoci snadno se vyhnout problému „po pádu nulová délka souboru“. Program by mohl existující soubor otevřít s O_REWRITE a získat tak nějakou speciální sémantiku. Nový soubor by neviditelný existoval vedle staré verze souboru tak dlouho, dokud by zůstal otevřený; během té doby by všechna další otevření souboru získala starou verzi. Jakmile bude soubor zavřen, jádro by ho atomicky přejmenovalo na dané jméno, čímž by se zajistilo, že kdyby během práce došlo k pádu, existovala by buď stará verze, nebo (kompletní) nová verze.

Tato volba by vývojářům aplikací zjednodušila přepisování existujících souborů bez obav o robustnost. Někdo by mohl namítnout, že by bylo lepší prostě tyto vývojáře naučit používat fsync(), ale jak poznamenává Rik, spoléhat se na vývojáře aplikací, že něco udělají dobře, moc nezafungovalo. Rikův návrh v současnosti postrádá patch, takže v blízké době do hlavní řady nezamíří.

Patenty na VFAT

Jak bylo diskutováno jinde, Andrew Tridgell zaslal nový, právníky schválený patch, který má obejít patenty Microsoftu na VFAT. Diskuze tentokrát nabrala trochu jiný směr; stále zní hlasy otrávené tím, že se dělají takové změny, aby se řešily problémy patentového systému Spojených států, ale tyto hlasy byly relativně tiché. Ne ale úplně tiché; Alan Cox řekl:

Dávat do jádra takovéhle záležitosti naštve každého, kdo nespadá pod zákony Spojených států, vytváří to situace, kde nelze o věcech diskutovat a pro výrobce to neznamená ani nejmenší změnu, protože ti stejně odstraní kód ze stromu zdrojových kódů – protože jak již bylo řečeno, snižuje to riziko.

Kromě toho mají vývojáři obavy z interoperability s ostatními implementacemi VFAT. Alan Cox žádá, aby se modifikovaný souborový systém, pokud se tento patch začlení, nenazýval „VFAT“, protože podle jeho mínění to už bude něco jiného. Ted Ts'o odpověděl, že „VFAT“ je i tak poněkud ošemetná záležitost. Není jisté, jestli tento problém bude vyřešen.

Cesta cestovatele

(Voyager's voyage). James Bottomley je hrdým vlastníkem archaického systému Voyager; Voyager je architektura založená x86 s mnoha zajímavými vlastnostmi – i když oproti pověstem pohon na páru není jednou z nich. Není jisté, jestli systémy založené na Voyageru běží ještě někde jinde mimo Jamesův sklep. Bez ohledu na to James spravuje architekturu Voyager léta.

Voyager byl nedávno vykopnut, když jeho kód přestal fungovat během procesu přepisu podpory subarchitektur x86. Když se ho James pokusil dostat zpátky, Ingo Molnár byl proti s tím, že cena patche není ospravedlněná ziskem z toho, že slouží tak malé základně uživatelů v hlavní řadě jádra. Ingo nakonec patch úplně odmítl, což vedlo ke zdánlivě neřešitelnému patu mezi těmito dvěma vývojáři.

Věci se změnily ve chvíli, kdy se Linus vložil do rozhovoru:

Ingo, „absurdní irelevance“ není důvod. Kdyby byl, ztratili bychom přibližně polovinu našich souborových systémů atd. Důvod není ani „tisíce řádků kódu“ ani „ne vždy to fungovalo“. Opět, kdyby to tak bylo, muselo bychom se zbavit asi všech ovladačů.

Ingo nakonec od mnoha svých stížností na patche Voyager ustoupil. Zbývá nicméně dlouhý seznam technických problémů ve stromu Voyageru a v tom, jak je spravován. James uznal, že tyto stížnosti jsou platné, a bude pracovat na jejich vyřešení. Nebude to dlouho trvat a vlastníci Voyageru (oba dva) budou opět mít plnou podporu své milované architektury v hlavní řadě jádra.

Čítače výkonnosti přidány do hlavní řady

Na čítače výkonnosti jsme se naposledy dívali v prosinci krátce poté, co se objevily. Od té doby na nich byla odvedena spousta práce, což skončilo tím, že byly začleněny během nedávno uzavřeného začleňovacího okna 2.6.31. Společně s tím byl do hlavní řady přidán také nástroj k jejich používání nazvaný perf.

Přidání perf do jaderného adresáře tools/ je jeden z překvapivějších aspektů začlenění čítačů výkonnosti. Vývojáři jádra se dlouhou dobu dívají na přidávání nástrojů pro uživatelský prostor do stromu jaderných zdrojových kódů s podezřením, ale ani několik námitek k tomto přístupu Linuse Torvaldse nepřesvědčilo. Pro vysvětlení poukázal na oprofile.

Trvalo doslova měsíce, než se uživatelské nástroje chytily a v CVS (nebo SVN?) se objevily patche, které podporují nové funkce; a i poté trvalo ještě déle, než se staly součástí vydání a byly převzaty distribucemi. Ve skutečnosti si dokonce nejsem jistý, že jsou součástí vydání již teď – pro Fedoru jsem musel napsat hlášení o chybě, abych do svých nástrojů dostal podporu pro atom a Nehalem: Myslím si, že vzali ten neoficiální patch.

Ostatní si nebyli tak jisti, že vývoj oprofile odděleně od jádra byl základní příčinou těchto selhání. Christoph Hellwig měl jiné vysvětlení: Neřekl bych, že oprofile byla katastrofa kvůli nějakému oddělení, ale protože jeho návrh byl špatný od prvního dne. Linus nicméně chce zkusit začlenění nástroje, aby viděl, k čemu to povede: Dejme novému přístupu šanci, uvidíme, jestli se nám tentokrát podaří vyhnout se včerejším chybám.

Nástroj perf jako takový je vcelku jednoduchý program pro příkazovou řádku, který lze přeložit v adresáři tools/perf. Také obsahuje nějakou dokumentaci v podobě man stránek, které jsou také k dispozici pomocí perf help (stejně tak v HTML a dalších formátech). Ve své nejjednodušší formě sbírá a hlásí nějaké statistiky pro zadaný příkaz:

$ perf stat ./hackbench 10
 Time: 4.174

  Performance counter stats for './hackbench 10':

     8134.135358  task-clock-msecs     #      1.859 CPUs
           23524  context-switches     #      0.003 M/sec
            1095  CPU-migrations       #      0.000 M/sec
           16964  page-faults          #      0.002 M/sec
     10734363561  cycles               #   1319.669 M/sec
     12281522014  instructions         #      1.144 IPC
       121964514  cache-references     #     14.994 M/sec
        10280836  cache-misses         #      1.264 M/sec

     4.376588249  seconds time elapsed.

To shrnuje události související s výkonem, které se objevily za běhu mikrobenchmarkovacího nástroje hackbench. Jde o souhrn hardwarových událostí (cykly, instrukce, odkazy na cache a stavy, kdy data nebyla nalezena v cache) stejně jako softwarových (task-clock-msec, přepnutí kontextu, migrace mezi CPU a výpadky stránky), které jsou získány od jaderného kódu a ne od jednotky pro sledování výkonnosti specifické pro procesor [performance monitoring unit, PMU]. V současnosti jsou hardwarové události k dispozici pro PMU od Intelu, AMD a PowerPC, ostatní architektury mají pouze podporu pro softwarové události.

K dispozici je také režim pro pozorování ve stylu top, který průběžně zobrazuje, které jaderné funkce jsou volány nejčastěji:

$ perf top -c 1000 -p 3216

------------------------------------------------------------------------------
   PerfTop:     360 irqs/sec  kernel:65.0% [1000 cycles],  (target_pid: 3216)
------------------------------------------------------------------------------

             samples    pcnt         RIP          kernel function
  ______     _______   _____   ________________   _______________

             1214.00 –  5.3% – 00000000c045cb4d : lock_acquire
             1148.00 –  5.0% – 00000000c045d1d3 : lock_release
              911.00 –  4.0% – 00000000c045d377 : lock_acquired
              509.00 –  2.2% – 00000000c05a0cbc : debug_locks_off
              490.00 –  2.2% – 00000000c05a2f08 : _raw_spin_trylock
              489.00 –  2.1% – 00000000c041d1d8 : read_hpet
              488.00 –  2.1% – 00000000c04419b8 : run_timer_softirq
              483.00 –  2.1% – 00000000c04d5f72 : do_sys_poll
              477.00 –  2.1% – 00000000c05a34a0 : debug_smp_processor_id
              462.00 –  2.0% – 00000000c043df85 : __do_softirq
              404.00 –  1.8% – 00000000c074d93f : sub_preempt_count
              353.00 –  1.5% – 00000000c074d9d2 : add_preempt_count
              338.00 –  1.5% – 00000000c0408a76 : native_sched_clock
              318.00 –  1.4% – 00000000c074b4c3 : _spin_lock_irqsave
              309.00 –  1.4% – 00000000c044ea10 : enqueue_hrtimer

Toto je statická verze výstupu z pohledu na poměrně klidný proces Firefoxu (pid 3216) se vzorkováním každých 1000 cyklů.

perf toho umí o dost víc. Podfunkce record sbírá data z čítačů výkonnosti do souboru perf.data, který lze použít v jiných příkazech:

$ perf record ./hackbench 10
Time: 4.348
[ perf record: Captured and wrote 2.528 MB perf.data (~110448 samples) ]

$ perf report --sort comm,dso,symbol | head -15

#
# (110146 samples)
#
# Overhead           Command  Shared Object              Symbol
# …..…  …..........…  …...................…  …...
#
    10.70%         hackbench  [kernel]                   [k] check_bytes_and_report
     9.07%         hackbench  [kernel]                   [k] slab_pad_check
     5.67%         hackbench  [kernel]                   [k] on_freelist
     5.28%         hackbench  [kernel]                   [k] lock_acquire
     5.03%         hackbench  [kernel]                   [k] lock_release
     3.19%         hackbench  [kernel]                   [k] init_object
     3.02%         hackbench  [kernel]                   [k] lock_acquired
     2.47%         hackbench  [kernel]                   [k] _raw_spin_trylock

Tento výstup ukazuje osm funkcí nejvíce vykonávaných v jádře za běhu hackbench. Stejný datový soubor lze také využít v  perf annotate (když je mu předáno jméno souboru a odpovídající soubor vmlinux), které zobrazí disasemblovaný kód funkce společně s počtem vzorků zaznamenaných při každé instrukci. Je zjevně obrovské bohatství informací, které lze z tohoto nástroje vytěžit.

Původní zaslání patchů čítačů výkonnosti přišlo jako překvapení pro Stéphana Eraniana, který dlouho pracoval na jiném řešení sledování výkonnosti, na „perfmon“. I když je stále k čítačům výkonnosti, které původně navrhl Ingo Molnár a Thomas Gleixner, poněkud skeptický, revidoval patche a poskytl dlouhé komentáře. Ingo také odpovídal dlouze, svou odpověď rozdělil na několik kousků, které lze najít ve vlákně.

Perfmon měl za cíl zpřístupnit co nejvíce dat z PMU do uživatelského prostoru, ale Ingo tento cíl explicitně odmítá:

Takže pro každou otázku „budete podporovat pokročilou funkci PMU X, Y a Z“, kterou položíš, bude odpověď na první úrovni „prosím, ukažte vývojáři příklad použití a integrujte ho do našich nástrojů, abychom viděli, jak to všechno funguje a jak použitelné to je“.

„Nástroj by to mohl chtít udělat“ není dostatečně dobrá odpověď. Nyní máme díky ,perf‘ fungující OSS nástroj, kde lze takové argumenty použít ve velmi specifických termínech: v patchích, číslech a srovnáních. Skutečná práce na nástroji, šťastní vývojáři a rychlejší aplikace jsou to, na čem nakonec záleží – ne na pouhém seznamu vlastností PMU, které zpřístupníme.

Jeho cílem, který pravděpodobně sdílí jeho spolusprávci Peter Zijlstra a Paul Mackerras, je zobecnit vlastnosti měření výkonností tak, aby nebyly závislé na konkrétním CPU a aby zapadly do vývojářského toku práce. Tvrdím, že dřív jsme pod Linuxem měli málo použitelných nástrojů, pokud vůbec nějaké, pro analýzu výkonnosti, a myslím si, že jsme v tomto ohledu stále v době kamenné a že před sebou v této oblasti máme spoustu práce. Z Ingovy perspektivy je snadné používání pro uživatele a vývojáře jednou z hlavních oblastí, kde perfmon neuspěl.

Ingo bez obalu poukazuje na to, že čítače výkonnosti stále vyžadují spoustu práce, ale framework je zde, takže vlastnosti lze přidávat k němu. Prozatím v jaderném adresáři Documentation/ není žádná dokumentace, ale lze předpokládat, že to bude někdy brzy vyřešeno. Ve shrnutí se čítače výkonnosti a nástroj perf zdají být velmi užitečným přírůstkem do jádra, takovým, který by měl v blízké budoucnosti začít přinášet úroky v podobě lepší výkonnosti.

API fanotify

Jednou z vlastností začleněných do 2.6.31 je nový framework pro upozorňování na události souborů „fsnotify“. Fsnotify slouží jako nová, společná podezdívka API inotify a dnotify, čímž se kód významně zjednodušuje. Toto zjednodušení, ať je jakkoliv vítané, nikdy nebylo skutečným účelem fsnotify. Fsnotify ve skutečnosti existuje jako podpůrná struktura pro fanotify, „systém pro upozorňování na zaslaný všechno“ [fscking all notification system], který byl nyní zaslán k revizím.

Fanotify bylo kdysi známo jako TALPA; jeho hlavním účelem je implementace vyhledávačů malwaru pro linuxové systémy. Když bylo TALPA poprvé představeno, na mnoha frontách narazilo na kritiku, z nichž obecná nechuť k vyhledávání malwaru jako bezpečnostní techniky nebyla nejmenší. Smutný fakt nicméně je, že mnoho zákazníku tuto funkci vyžaduje, takže existuje trh pro takové produkty pro Linux. Prozatím vyhledávací produkty vyžadovaly nechutné techniky jako je zaháčkování v tabulce systémových volání nebo nahrávání pouze binárních bezpečnostních modulů. Fanotify, jak se doufá, pomůže tyto produkty zbavit takových hacků a umožní jim úplně vypadnout z jádra.

API pro uživatelský prostor, které fanotify používá, je v očích Jonathana Corbeta, autora článku, poněkud podivné. Aplikace fanotify začne otevřením socketu s protokolem nové rodiny PF_FANOTIFY. Tento socket musí být spojen s „adresou“ popsanou takto:

struct fanotify_addr {
    sa_family_t family;
    __u32 priority;
    __u32 group_num;
    __u32 mask;
    __u32 timeout;
    __u32 unused[16];
};

Pole family by mělo být AF_FANOTIFY. Pole priority se používá k určení, který socket obdrží specifickou událost, pokud jich existuje víc; vyhrávají nižší hodnoty. group_num používá vrstva fsnotify k identifikaci skupiny posluchačů události. Pole timeout se v současnosti zdá být nevyužívané. A nakonec mask popisuje události, které aplikaci zajímají:

• FAN_ACCESS: jakýkoliv přístup k souboru
• FAN_MODIFY: modifikace souboru
• FAN_CLOSE: zavření souboru
• FAN_OPEN: volání open()
• FAN_ACCESS_PERM: stejně jako FAN_ACCESS, kromě toho, že je proces pokoušející se přistoupit k souboru pozastaven, dokud se klient fanotify nerozhodne, jestli operaci povolit
• FAN_OPEN_PERM: jako FAN_OPEN, ale s kontrolou práv
• FAN_EVENT_ON_CHILD: volajícího zajímají všechny události v celé adresářové hierarchii
• FAN_GLOBAL_LISTENER: upozorňovat na události u všech souborů v systému

Jakmile je socket připojen, aplikace se může dozvědět o aktivitě souborového systému použitím známého systémového volání pro načítání událostí getsockopt(). Volání getsockopt() s SOL_FANOTIFY jako úrovně a FANOTIFY_GET_EVENT jako volby vrátí jednu nebo více struktur jako je tato:

struct fanotify_event_metadata {
    __u32 event_len;
    __s32 fd;
    __u32 mask;
    __u32 f_flags;
    pid_t pid;
    pid_t tgid;
    __u64 cookie;
};

Zde je fd popisovač souboru, o který se jedná, otevřený pouze pro čtení, mask popisuje události (používají se příznaky popsané výše), f_flags je kopie příznaků poskytnutých procesem, který se k souboru pokouší přistupovat a pid a tgid proces identifikují (v současnosti způsobem, který nezná jmenné prostory). Pokud událost potřebuje povolení od aplikace, cookie bude obsahovat hodnotu, kterou lze toto povolení udělit nebo zamítnout.

Všimněte si, že by poskytnutý popisovač souboru měl nakonec být zavřen; jinak by se tyto popisovače poměrně rychle nahromadily.

Když je rozhodnuto o udělení přístupu, aplikace musí jádro upozornit voláním setsockopt() s použitím volby FANOTIFY_ACCESS_RESPONSE a struktury jako:

struct fanotify_so_access {
    __u64 cookie;
    __u32 response;
};

Měla by být poskytnuta hodnota cookie z události a odpověď by měla být jedna z FAN_ALLOW a FAN_DENY. Pokud aplikace neodpoví do pěti vteřin, jádro akci povolí. Pět sekund by mělo být pro prohledání souboru dost, ale pro některé další aplikace fanotify, jako je například systém pro správu hierarchického úložiště, by to mohl být problém. Vývojář fanitofy Eric Paris poznamenává, že časem bude přidána vlastnost, která umožní pozdržet odpověď nekonečně.

Je možné nastavit sadu souborů, na jejichž události se upozorňuje, pomocí operací FANOTIFY_SET_MARK, FANOTIFY_REMOVE_MARK a FANOTIFY_CLEAR_MARKS. Pokud je při připojování [bind] předána volba FAN_GLOBAL_LISTENER, všechny soubory jsou „označeny“ hned zpočátku. FANOTIFY_REMOVE_MARK lze použít k odstranění těch, které nejsou zajímavé. Jinak musí být alespoň jednou zavoláno FANOTIFY_SET_MARK, aby byly nějaké události vraceny.

Některé detaily byly vynechány, ale to, co je zmíněno výše, pokrývá hlavní části API fanotify. Komentáře k tomuto zaslání byly relativně vzácné; opozice k této vlastnosti, zdá se, během posledního roku zmizela. Co zbývá, je udělat API dobře; Jonathan má podezření, že používání getsockopt() jako rozhraní pro načítání událostí může dřív či později vyvolat nějaké vrásky. Jakmile ale bude vyžehleno toto, je tu dobrá šance, že se do Linuxu dostane obecné rozhraní pro upozorňování a povolování přístupu k souborům.

       

Komentáře

[HonzaRez]

Koukám, že ten Neil Brown je asi Vládce Stínů... Hlavně aby mu v tom nevznikl Chaos.

[Filip Jirsák]

ale protože jeho návrh byl špatný do prvního dne

s/do/od/

„systém pro upozorňování na zaslaný všechno“

Nebylo by lepší třeba „systém pro upozorňování na cokoli“?

[Robert Krátký]

„systém pro upozorňování na zaslaný všechno“

Nebylo by lepší třeba „systém pro upozorňování na cokoli“?

Ani ne... je to slovní hříčka, kterou se IMHO povedlo docela obstojně převést do češtiny. "fscking" -> "zaslaný".

[Filip Jirsák]

Aha, toho jsem si nevšiml.

[petr_p]

architektura založená na x86

[Jendа]

Ten Alanův přístup se mi líbí :-P Že by začali ditributoři dodávat balíčky jako linux-image-2.6.30-1-686-us, linux-image-2.6.30-1-686-ru a podobné? Pokud by třeba Debian měl v kernelech tu volbu zapnutou, určitě bych byl pro vytvoření non-us kernelů. Už teď máme oddělené repozitáře pro USA a zbytek světa, tak proč ne. (IMHO by byl ale lepší jeden repozitář, kde by byl balíček legal-us, který by měl v conflicts třeba tam-patentované kodeky)

[trekker.dk]

Souhlas - přece nebudeme vyhazovat funkce z jádra jenom proto, že nějaké hovado v USA vymyslelo takový patentový systém, jaký tam mají. Jenom když si vzpomenu na nedávný článek o KSM, kde se místo jednoduchého hashe vymýšlí hovadiny, protože nikdo se nechce pokusit patent zneplatnit (přestože existuje prior art, tudíž by to s největší pravděpodobností uspělo)