Jaderné noviny – 15. 10. 2014: Začleňovací okno verze 3.18 – 2. část

15. 11. 2014 | Tadeáš Pelech | Jaderné noviny | 2736×

Aktuální verze jádra: 3.18. Citáty týdne. Začleňovací okno verze 3.18 – 2. část. Implementace virtuálních systémových volání.

Obsah

• Aktuální verze jádra: 3.18
• Citáty týdne
• Začleňovací okno verze 3.18 – 2. část
• Implementace virtuálních systémových volání

Aktuální verze jádra: 3.18

Začleňovací okno 3.18 je otevřené, takže není žádné aktuální vývojové jádro. Do hlavního stromu si našla cestu spousta změn; podrobnosti najdete v samostatném článku níže.

Stabilní aktualizace: verze 3.16.5 (oznámení), 3.14.21 (oznámení) a 3.10.57 (oznámení) byly vydány dne 9. října, následované dne 15. října verzemi 3.17.1 (oznámení), 3.16.6 (oznámení), 3.14.22 (oznámení) a 3.10.58 (oznámení).

Citáty týdne

Až příště lidi ze sítí řeknou, že jim úložiště kradou nápady, jen budu tiše sedět a ukážu na xmit_more.

– Jens Axboe (odkaz)

Když půjde všechno dobře, nikdy nebudeme vyžadovat přidání skutečného zdrojového kódu C pro podporu platformy arm64, pokud bude tato architektura jasně definovaná a pokud z ní bude přesunuta spousta věcí vázaných na platformu do ovladačů pro architekturu arm32.

– Arnda Bergmann, věčný optimista (odkaz)

Pokud má recenzent nějaké otázky, musíme je brát jako závadu v opravě. Oprava není dokončena, dokud se nedá přečíst bez nutnosti doplňujících dotazů.

– Andrew Morton (odkaz)

Začleňovací okno verze 3.18 – 2. část

V době psaní tohoto textu vybral Linus 8 722 sad změn bez začlenění do hlavního repozitáře pro začleňovací okno 3.18. V tomto okamžiku by se dalo rozumně usuzovat, že se začleňovací okno blíží dokončení, i když Linus původně mluvil o tom, že ho nechá otevřené do 26. října. Váš editor by si troufl odhadovat, že se toto začleňovací okno zavře spíše o něco dříve.

Od souhrnu z minulého týdne bylo začleněno ještě 5 786 změn. Mezi zajímavější změny viditelné uživatelem patří:

• Architektura arm64 nyní podporuje kompilaci just-in-time programů rozšířeného filtru paketů Berkeley (eBPF).
• Systémové volání bpf() je nyní v hlavním stromu. Háčky pro použití tohoto kódu (například při trasování nebo filtrování paketů) budou trvat o něco déle, ale základní podpora pro „univerzální virtuální stroj“ je nyní v jádru k dispozici.
• Byla začleneněna zlepšení výkonu sítí popsané v tomto článku. Mimo jiné umožňují relativně malým systémům řídit vysokorychlostní rozhraní maximální možnou rychlostí, dokonce i při přenosu malých paketů. Výkon s malými pakety je v Linuxu stále problematický, jedná se tedy o významné zlepšení.
• Byl začleněn subsystém foo-over-UDP; poskytuje podporu pro tunelovací protokoly přes UDP.
• Nově je podporován algoritmus řízení zahlcení TCP datových center (DCTCP). Spoustu informací najdete ve zprávě o zápisu a ještě víc jich najdete na této stránce.
• Nově je podporován protokol Obecné zapouzdření virtualizace sítě (Geneve); další informace najdete na této stránce.
• Systémové volání fanotify_init() v důsledku chyby vždy ignoroval možnost O_CLOEXEC (která vyžaduje, aby byl výsledný popisovač souboru uzavřen, pokud program zavolá exec()). Ve verzi 3.18 byla tato chyba opravena. Objevily se obavy, že by aplikace mohly tiše spoléhat na nedodržování této možnosti; vývojáři pracující s rozhraním fanotify by tedy měli této změně věnovat zvýšenou pozornost.
• Systémové volání prctl() podporuje novou operace PR_SET_MM_MAP, která nastavuje základní parametry rozvržení prostoru adres procesu: kde jsou oblasti kódu a dat, pointer přerušení, zásobník, atd. Podrobné informace o fungování tohoto rozhraní najdete ve zprávě o protokolu změn.
• Nový subsystém Xen „pvSCSI“ umožňuje hostům Xen ovládat zařízení SCSI, které jim byly přiřazeny.
• Architektura SPARC64 nyní používá čtyřúrovňové tabulky stránek, což výrazně zvyšuje objem adresovatelné paměti.
• Subsystém povinného řízení přístupu Smack má nový režim „bring-up“, který lze použít k záznamu oprávnění, která proces potřebuje k provedení. Je určen k použití při zápisu pravidel Smack, pak k sestavení v produkčních systémech.
• Jako obvykle je seznam funkcí přidaných do subsystému událostí perf a uživatelského prostoru nástroje perf je dlouhý; podrobnosti viz tato zpráva o zápisu.
• Podpora nového hardwaru zahrnuje:
• Systémy a procesory: Systémy na čipu (SoC) Hisilicon HiP04 Cortex A15, SoC Amlogic Meson6 (8726MX), SoC Renesas R-Car E2 (R8A77940), SoC Broadcom BCM63xx DSL SoC, SoC Atmel SAMA5D4 a SoC Cavium Inc. Thunder.
• Audio: Kodeky Cirrus Logic CS35L32, obecné zvukové karty Freescale, zvukové kodeky Everest ES8328, zvukové kodeky Freescale ES8328 a zesilovače zvuku Analog Devices SSM4567.
• Různé: Víceportové řadiče DDR SDRAM Atmel, řadiče paměti Altera SDRAM, řadiče TI Keystone Navigator, řadiče TI Keystone PCIe, hodiny reálného času Allwinner A31, řadiče Texas Instruments Keystone 2 IRQ , řadiče APM X-gen GPIO a PCIe, hostitelské bridge Xilinx AXI PCIe, řadiče správy základní desky MEN 14F021P00, koherentní akcelerátory IBM, hodiny reálného času Rockchip RK808 a hodiny reálného času Maxim 77802.
• Sítě: Řadiče Bosch M_CAN, řadiče sběrnice Broadcom UniMAC MDIO, Ethernetové přepínače Broadcom Starfighter 2, Ethernetové hostitelské rozhraní přepínače Intel FM10000, Ethernetové přepínače Marvell 88E6171 a Ethernetové řadiče Qualcomm Atheros QCA7000.
• Video4Linux: Společné moduly rozhraní CIMaX SP2/SP2HF, zařízení TechnoTrend TVStick CT2-4650 CI, softwarově definovaná rádia HackRF, přijímače USB DVBSky, IČ dálkové ovládání Hisilicon hix5hd2, tunery MaxLinear MxL301RF, tunery Sharp QM1D1C0042, demodulátory Toshiba TC90522 a karty Earthsoft PT3 PCIe.

Mezi změny viditelné pro vývojáře jádra patří:

• Dlouholetý zkušební ovladač „vivi“ v subsystému Video4Linux byl nahrazen novým ovladačem nazvaný „vivid“. Tento ovladač lze použít jako příklad, jak by měly být napsány ovladače V4L a modul pro testování programů v uživatelském prostoru.
• Byl sloučen subsystém úloh RCU; umožňuje chování ve stylu RCU pod uvolněnou sadou pravidel. Podrobnosti viz tento článek.
• V jádru je nyní k dispozici strom zařízení „resolver“. Resolver funguje jako jakýsi linker, který řeší odkazy na sekce stromu zařízení („phandles“) v době načtení. Tato práce je součástí většího úsilí při realizaci stromů zařízení konfigurovatelných v době spuštění.

Jak je vidět, slučovací okno verze 3.18 v podstatě sotva začalo. Lze očekávat, že tempo v blízké budoucnosti naroste, jakmile Linus dokončí své cesty a dorazí do Düsseldorfu na LinuxCon, CloudOpen, ELCE, KVM Fórum, LPC atd.

Implementace virtuálních systémových volání

„Virtuální dynamický sdílený objekt“ (vDSO) je malá sdílená knihovna exportovaná jádrem k akceleraci provádění některých systémových volání, která nutně nemusí být spuštěna v prostoru jádra. Zatímco vývojáři jádra se shodli na exportu malé sady funkcí prostřednictvím vDSO, vývojářům nic brání přidávat své vlastní. Pokud aplikace potřebuje často a rychle získat nějaké informace z jádra, může být užitečným řešení funkce vDSO. Úvod do vDSO viz stránka nápovědy vDSO(7).

Tento článek ukazuje, jak je programovací technika používaná k implementaci těchto funkcí založena především na chytrých dodatcích k skriptu linker Linuxu a jak lze stejný postup použít k implementaci funkcí, které rychle vypočítávají hodnoty založené na proměnných jádra. Můžeme ji brát jako jakýsi doplněk k této sérii na pravidelných systémových voláních. V knihovně vDSO jsou zahrnuty různé sady funkcí v závislosti na hardwarové platformě. Implementace popsaná zde odkazuje na architekturu x86_64.

Virtuální systémová volání

Když proces vyvolá systémové volání, spustí zvláštní instrukce nutící procesor k přepnutí do režimu jádra, uloží obsah registrů do zásobníku režimu jádra a spustí provádění funkce jádra. Když je systémové volání obslouženo, jádro obnoví obsah registrů uložených v zásobníku režimu jádra a pomocí dalších zvláštních instrukcí pokračuje v provádění procesu uživatelského prostoru.

Uvedení systémových volání přistupujících k informacím prostoru jádra do adresního prostoru procesu by je urychlilo, protože by mohly načíst požadovanou hodnotu z adresního prostoru jádra bez těch přepnutí kontextu. Pro tento typ emulace se samozřejmě hodí jen systémová volání pouze pro čtení, protože procesy v uživatelském prostoru nemají povolen zápis do adresního prostoru jádra. Funkce uživatelského prostoru, které emulují systémová volání, se nazývají virtuální systémová volání.

Implementace vDSO v Linux na x86_64 nabízí čtyři z těchto virtuálních systémových volání: __vdso_clock_gettime(), __vdso_gettimeofday(), __vdso_time() a __vdso_getcpu(). Odpovídají standardním systémovým voláním clock_gettime(), gettimeofday(), time() a getcpu().

O kolik rychlejší je virtuální systémové volání než standardní? To samozřejmě záleží na hardwarové platformě a na typu procesoru. Na desce P6T SE ASUS s procesorem Intel 2,8 GHz Core i7, je průměrný čas nutný k provedení standardního systémového volání gettimeofday() je 90,5 mikrosekund, průměrný čas na odpovídající virtuální systémové volání je 22,3 mikrosekund; tedy výrazné zlepšení, které odůvodňuje úsilí vynaložené při vypracování aplikačního rámce vDSO.

Co je vDSO?

Uvažujete-li o vDSO, měli byste mít na paměti, že tento výraz má dva různé významy: (1) jedná se o dynamickou knihovnu, ale tento výraz také slouží k označení (2) oblasti paměti patřící do adresního prostoru každého procesu v uživatelském režimu. Oblast paměti vDSO – jako většina ostatních oblastí paměti procesu – má svou polohu standardně náhodně vybranou pokaždé, když je namapován. Randomizace rozložení adresního prostoru je forma obrany proti bezpečnostním dírám.

Pokud pomocí příkazu „cat /proc/pid/maps“ zobrazíte oblasti paměti vlastněné procesem s ID procesu rovnajícím se pid, vypíše se něco jako:

    7ffffb892000-7ffffb893000 r-xp 00000000 00:00 0          [vdso]

což popisuje atributy této zvláštní oblasti. Počáteční adresa vDSO, 0x7ffffb892000, je menší než PAGE_OFFSET, (což je 0xffff880000000000 na počítačích s architekturou x86-64), tím, že je vDSO součástí uživatelského adresního prostoru. Finální adresa, tedy 0x7ffffb893000, ukazuje, že vDSO zabírá jednu 4kB stránku. Příznak oprávnění r-xp určuje, že jsou povolena oprávnění pro čtení a spuštění a že oblast je soukromá (nesdílená). Poslední tři pole označují, že region není mapován ze žádného souboru, a nemá tedy žádný inode.

Binární kód uložený v oblasti paměti vDSO má formát dynamické knihovny. Jestliže vypíšete kód z oblasti paměti vDSO do souboru a použijete na něj příkaz file, získáte:

    sdílený objekt ELF 64-bit LSB, x86-64, verze 1 (SYSV), dynamicky propojený, stripovaný

Všechny Linuxové sdílené dynamické knihovny, jako například glibc, používají formát ELF.

Pokud dekompilujete soubor obsahující oblast paměti vDSO, najdete kód sestavení čtyř virtuálních systémových volání zmíněných dříve. V jádru 3.15 je pro uložení hlavičky ELF a kódu virtuálního systémového volání ve vDSO zapotřebí pouze 2 733 z 4 096 bajtů. To znamená, že stále existuje prostor pro další funkce.

Protože vDSO je plně vytvořený obraz ELF, můžete na něm provádět vyhledávání symbolů. To umožňuje přidání nových symbolů s novými verzemi jádra a umožňuje knihovně C zjistit dostupné funkce v době běhu při spuštění v různých verzích jádra. Spustíte-li „readelf –s“ na soubor obsahující oblast paměti vDSO, získáte výpis položek v části tabulky symbolů souboru:

Tabulka symbolů „.dynsym“ obsahuje 11 položek:
   Num:    Hodnota          Typ velikosti    Vazba   Vis      Název Ndx
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: ffffffffff700330     0 SECTION LOCAL  DEFAULT    7
     2: ffffffffff700600   727 FUNC    WEAK   DEFAULT   13 clock_gettime@@LINUX_2.6
     3: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6
     4: ffffffffff7008e0   365 FUNC    GLOBAL DEFAULT   13 __vdso_gettimeofday@@LINUX_2.6
     5: ffffffffff700a70    61 FUNC    GLOBAL DEFAULT   13 __vdso_getcpu@@LINUX_2.6
     6: ffffffffff7008e0   365 FUNC    WEAK   DEFAULT   13 gettimeofday@@LINUX_2.6
     7: ffffffffff700a50    22 FUNC    WEAK   DEFAULT   13 time@@LINUX_2.6
     8: ffffffffff700a70    61 FUNC    WEAK   DEFAULT   13 getcpu@@LINUX_2.6
     9: ffffffffff700600   727 FUNC    GLOBAL DEFAULT   13 __vdso_clock_gettime@@LINUX_2.6
    10: ffffffffff700a50    22 FUNC    GLOBAL DEFAULT   13 __vdso_time@@LINUX_2.6

Zde si můžete prohlédnout různé funkce v oblasti vDSO.

Kde jsou data?

Dosud jsme se nezmiňovali o tom, jak virtuální systémové volání načte proměnné z adresního prostoru jádra. Je to nejspíš nejzajímavější a nejméně zdokumentovaná funkce subsystému vDSO. Vezměme si pro příklad virtuální systémové volání __vdso_gettimeofday(). Tato funkce načte data jádra, která potřebuje, z proměnné s názvem vsyscall_gtod_data. Tato proměnná má dvě různé adresy:

• První z nich je adresa běžného prostoru jádra, jehož hodnota je větší než PAGE_OFFSET. Když se podíváte na soubor System.map, zjistíte, že tento symbol má adresu jako ffffffff81c76080.
• Druhá adresa je v oblasti zvané „stránka vvar“. Základní adresu (VVAR_ADDRESS) této stránky je definována v jádru na 0xffffffffff5ff000, téměř na konci 64bitového adresního prostoru. Tato stránka je kódu uživatelského prostoru k dispozici jen pro čtení.

Obě adresy samozřejmě mapují na stejnou fyzickou adresu, tj. odkazují na stejný rámce stránky.

Proměnné jsou vytvořeny v této stránce makrem DECLARE_VVAR(). Například, deklarace vsyscall_gtod_data je umístí na offset 128 na stránce vvar. Adresa této proměnné viditelná z uživatelského prostoru je tedy: 0xffffffffff5ff000 + 128. Aby linker rozpoznal proměnné existující na stránce vvar, makro DECLARE_VVAR() je umístí do speciální sekce .vvar v binárním obrazu jádra (další informace viz speciální sekce v binárních kódech Linuxu).

Kód spuštěný v rámci jádra používá adresu prostoru jádra pro přístup k  vsyscall_gtod_data. Virtuální systémová volání, která běží v uživatelském režimu, musí použít tuto druhou adresu. K proměnným umístěným na stránce vDSO přistupují procesy v uživatelském režimu popisovače segmentu __USER_DS. Lze z nich číst, ale nelze do nich zapisovat. Jako další preventivní opatření je Linux deklaruje jako const tak, aby kompilátor zjistil jakýkoli pokus o zápis do nich.

Hodnoty proměnných vvar jsou nastavené podle hodnot jiných proměnných jádra, která nejsou přístupná kódu uživatelského prostoru. Když jádro upravuje hodnotu jedné z vnitřních proměnných, související proměnné na stránce vvar je třeba aktualizovat. V Linuxu tuto úlohu provádí funkce timekeeping_update(), která je například vyvolána při každé změně hodnoty jiffies, počtu cyklů uplynulých od spuštění systému.

Přidání funkce do stránky vDSO

Linuxová implementace vDSO usnadňuje vývojářům jádra přidat nové funkce do stránky vDSO. Pokud se podíváte na kód čtyř virtuálních systémových volání, všimnete si, že tři z nich načítají data z jádra, která potřebují z proměnné vvar s názvem vsyscall_gtod_data typu struct vsyscall_gtod_data. To čtvrté, tedy, __vdso_getcpu(), nic nenačte: získá index procesoru provedením instrukce rdtscp.

Další důležitý bod je, že parametr předaný timekeeping_update(), funkci, která aktualizuje pole z  vsyscall_gtod_data, je ukazatel na globální proměnnou jádra s názvem timekeeper typu struct timekeeper. Když funkce jádra aktualizuje pole timekeeper vztahující se k virtuálnímu systémovému volání, lze předpokládat, že v nejbližší době bude mít tato změna vliv na vsyscall_gtod_data, a tedy na hodnoty vrácené voláními virtuálního systému. Jinými slovy, funkce jádra, která aktualizuje pole timekeeper, jsou volně spojena s virtuálním systémovým voláním.

Nejjednodušší způsob, jak definovat novou funkci vDSO, je vytvořit podobné spojení mezi vnitřními proměnnými jádra a proměnnou přidanou do stránky vvar. Funkce update_vsyscall(), jejíž volání můžete očekávat s relativně vysokou frekvencí, může být podle potřeby rozšířena tak, aby přesouvala data do stránky vvar.

Zde je několik tipů, které vám mohou pomoci při vývoji nových funkcí vDSO:

• Při programování funkce vDSO nezapomeňte, že žádná externí funkce jádra ani globální proměnná jádra se nemůže objevit v kódu, pouze automatické proměnné (zásobníky) a proměnné vvar. Vzhledem k tomu, že je funkce spuštěna v uživatelském režimu, identifikátory prostoru jádra nejsou linkeru známy.
• Skript linkeru Linuxu, který zpracovává funkce vDSO, musí vědět, že je přidána nová funkce, například __vdso_foo(). Za tímto účelem je nutné přidat pár řádků jako následující

  linux/arch/x86/vdso/vdso.lds.S:
      foo;
      __vdso_foo;

  Musíte také přidat následující řádky na konec definice __vdso_foo() v adresáři linux/arch/x86/vdso/:

      int foo(struct fd *fd) __attribute__((weak, alias("__vdso_foo")));

  Tímto způsobem se z  foo() stává slabý alias pro __vdso_foo().
• Nezapomeňte změnit kód update_vsyscall(), jednoduché přenosové funkce vyvolané pomocí timekeeping_update(), která zkopíruje některá pole z  timekeeper do proměnné vsyscall_gtod_data. Tato funkce může také kopírovat požadovaná data do vaší nové proměnné ve stránce vvar.
• Pokud je prototyp nové funkce: int __vdso_foo (struct fd * fd), musí být testovací program, řekněme test_foo.c, který vyvolá __vdso_foo(), musí být linkovaný jako:

      gcc -o test_foo linux/arch/x86/vdso/vdso.so test_foo.c

  protože kód __vdso_foo() je součástí knihovny vdso.so. Pokud je foo definovaná jako slabý alias pro __vdso_foo, můžete v testovacím programu také volat foo() místo __vdso_foo().

Závěr

Programovací technika používaná k implementaci funkce vDSO je založena na některých chytrých dodatcích k skriptu linkeru Linuxu, které umožňují funkcím jádra definovaným v linuxovém jádru linkování v adresním prostoru všech procesů uživatelského režimu. Nové funkce vDSO lze snadno implementovat k získání informací o aktuálním stavu jádra (počet procesů v systému, počet volných stránek, apod.). Pokud máte informace, které musíte získávat z jádra s vysokou frekvencí a nízkou režií, může mechanismus vDSO poskytnout ty nástroje, které potřebujete.

       

Komentáře

[ebik]

Poslední 3 odrážky před závěrem jsou ve skutečnosti jedna, špatně sformátovaná.

[ebik]

Ha, už je to opravené.

[Petr Ježek]

Díky za obsáhlý report. Člověk rád pozapomene na něco z toho, co se tu naštěstí v kostce objeví.

[zde]

No ja nevim, z 90 na 22 uS, to jako ma byt nejake zrychlení? Kdyby se do vvar page lezlo primo ( promenne jsou na fixnich adresach) a ne skrz zcestny vdso, tak by to mozna rychly bylo.