Jaderné noviny – 23. 5. 2013: Komprimovaný swap v paměti

10. 6. 2013 | Luboš Doležel | Jaderné noviny | 4188×

Aktuální verze jádra: 3.10-rc2. Vyšlo Ktap 1.0. Začlenění zswap. Obsluha ethernetových karet s nízkou latencí.

Obsah

• Aktuální verze jádra: 3.10-rc2
• Vyšlo Ktap 1.0
• Začlenění zswap
• Obsluha ethernetových karet s nízkou latencí

Aktuální verze jádra: 3.10-rc2

Aktuální vývojová verze jádra je 3.10-rc2 vydaná 20. května. Linus k ní řekl: Jelikož je to -rc2, tak je velikost přijatelná, i když jsem přetáhl několik věcí, u kterých bych to u vyšších -rc odmítl. Takže to není ani vyloženě malé. Máme tam aktualizace v architekturách (PPC, MIPS, PA-RISC), opravy v ovladačích (síť, GPU, target, xen) a změny v systémech souborů (btrfs, ext4 a cepth – rbd).

Stabilní aktualizace: verze 3.9.3, 3.4.46 a 3.0.79 vyšly 19. května; verze 3.6.11.4 vyšla 20. května.

Vyšlo Ktap 1.0

Nový nástroj pro trasování jádra nazvaný „ktap“ dospěl do první verze. KTAP má odlišné principy návrhu oproti linuxovému hlavnímu dynamickému trasovacímu jazyku, který je založený na bajtkódu, proto nezávisí na GCC, nevyžaduje kompilaci jaderného modulu, je bezpečné ho používat v produkčním prostředí a naplňuje potřeby trasování v prostředí embedded zařízení. Je v rané fázi vývoje; projekt hledá přispěvatele a testery.

Začlenění zswap

Jak už se psalo dříve, bylo rozhodnuto, že bude začleněn zswap, subsystém pro komprimovanou swap cache, zatímco poněkud komplexní subsystém „zcache“ zůstane zatím bokem. Jenže rozhodnutí učiněná na konferencích nezřídka končí komplikacemi při realizaci; a tak tomu bylo i tentokrát.

Vývojář zswap Seth Jennings náležitě zaslal kód pro zvážení v průběhu vývojového cyklu 3.11. Brzy ale narazil na odpor ze strany vývojáře zcache Dana Magenheimera; Dan souhlasil se začleněním zswap obecně, ale měl jisté obavy o špatný výkon zswap v určitých situacích. Podle Dana by bylo lepší tyto problémy před zařazením kódu opravit:

Řekl bych, že skutečnou výzvou pro zswap (nebo zcache) a jeho význam pro distribuce a koncové uživatele je mít to dobře udělané DŘÍVE NEŽ uživatelé začnou hlásit chyby týkající se podivného výkonu. Po něčem takovém by uživatelé a distribuce jednoduše nastavili hodnotu 0 % (neboli vypnutli zswap), protože zswap by někdy nepředvídatelně bylo na prd.

Diskuze se točila na místě, jak se to u debat ohledně komprese v jádře stává. Nakonec to ale za vývojáře správy paměti (až na Dana) nejlépe shrnul asi Mel Gorman:

Řekl bych, že je tam hodně škaredých věcí a sklon k podivným výkonnostním problémům. Během revidování kódu jsem si stěžoval na spousty různých částí kódu, ale vize, že budou opraveny mimo strom nebo ve staging, jako to bylo doposud, je evidentně zcela mylná.

Výsledkem je tedy pravděpodobně to, že sice dojde k začlenění zswap do verze 3.11, ale se spoustou varování. Pak doufejme bude zvýšená viditelnost kódu motivovat vývojáře k přípravě patchů a vylepšování kódu tak, aby zswap byl nakonec vhodný k produkčnímu nasazení.

Obsluha ethernetových karet s nízkou latencí

O Linuxu se obecně traduje, že má jednu z nejrozsáhlejších a nejrychlejších podpor síťování, co existuje. Ale vždy se najde někdo, kdo není s tím, co je, spokojený a snaží se to nahradit něčím, co je více uzpůsobeno jeho potřebám. Jedné takové skupině lidí jde o extrémně nízkou latenci, kdy je na každý příchozí paket nutné odpovědět co nejrychleji. Do této kategorie patří systémy pro rychlé obchodování, ale našly by se i další. Tito lidé mají často pokušení obejít síťování v jádře a nahradit jej v uživatelském prostoru (nebo v hardwaru), ale to přináší své vlastní problémy. Relativně malý patch pro síťový subsystém může toto pokušení alespoň u některých lidí omezit.

Síťová rozhraní jako většina rozumných periferních zařízení dokáže přerušovat CPU při příchodu každého paketu. Ale i středně zatížené rozhraní může přijímat stovky nebo tisíce paketů za sekundu; mít přerušení na každý paket by rychle zavalilo procesor režií spojenou s přerušeními, až by pak zbývalo málo času na užitečnou práci. Proto většina ovladačů rozhraní zakáže přerušení při každém paketu, jakmile provoz dosáhne určité úrovně, a ve spolupráci s vrstvou pro síťování se pak příležitostně dotazuje zařízení na nové pakety. Tento přístup má řadu výhod: vyhýbáme se záplavě přerušení, příchozí pakety mohou být zpracovávány efektivněji po dávkách a pokud je v reakci na zátěž nutné pakety zahodit, pak je možné je odstranit dřív, než se dostanou dál. Dotazování má tedy přednosti v téměř všech situacích, kde je nějaký větší provoz.

Zájemci o extrémně nízkou latenci ale vidí věci jinak. Čas mezi příchodem paketu a následujícím dotazem na zařízení je právě tím typem latence, které se chtějí vyhnout. Opětovné povolení přerušení také není řešení; přerušení jsou také zdrojem latence. Proto je tu zájem o řešení v uživatelském prostoru, kde je možné dotazovat se na nové pakety, kdykoliv je možné je začít zpracovávat.

Eliezer Tamir zaslal alternativní řešení v podobě patche pro dotazování síťového zařízení s nízkou latencí. S tímto patchem může aplikace povolit dotazování na nové pakety přímo na ovladači zařízení s tím výsledkem, že si pakety rychle najdou cestu do síťové vrstvy.

Patch přidává nové pole do struktury net_device_ops:

int (*ndo_ll_poll)(struct napi_struct *dev);

Tato funkce by měla způsobit, že se ovladač dotáže na nové pakety a ihned je předá síťové vrstvě; neměla by blokovat. Návratovou hodnotou je počet paketů, které byly takto předány. Jinou možností je návratová hodnota LL_FLUSH_BUSY znamenající, že jiná probíhající operace zabránila zpracování paketů (například nějaký zámek) nebo LL_FLUSH_FAILED značící chybu. LL_FLUSH_FAILED způsobí konec dotazování, zatímco LL_FLUSH_BUSY je zdá se zcela ignorováno.

V rámci síťové vrstvy je funkce ndo_ll_poll() zavolána, kdykoliv to vypadá jako dobrý nápad. Například při volání poll(). Sockety označené jako neblokující se budou dotazovat jen jednou; jinak bude dotazování pokračovat tak dlouho, než se do síťové vrstvy dostanou nějaké pakety určené pro daný socket, než bude dosažen maximální čas stanovený hodnotou volby ip_low_latency_poll v sysctl. Výchozí hdonotou pro tuto volbu je nula (což znamená, že dotaz na rozhraní proběhne jen jednou), ale „doporučovanou hodnotou“ je 50 µs. Pokud tedy v době volání poll() existují nějaké nezpracované pakety (nebo přijdou krátce poté), budou rychle vloženy do síťové vrstvy a okamžitě zpřístupněny, bez nutnosti čekat na to, než se ovladač sám dotáže zařízení.

Další patch přidává dodatečné volání do kódu TCP. Pokud je použito read() na aktivním spojení TCP a nejsou žádná data k vrácení do uživatelského prostoru, pak se ovladač dotáže, jestli je možné něco protlačit do systému. Proto není u TCP socketů nutné další volání poll().

Tento patch usnadňuje dotazování zařízení přímo z aplikací; jakmile je funkce nakonfigurována v jádře, už není nutné dělat v aplikacích žádné změny. Na druhou stranu to znamená to, že každý poll() nebo TCP read() vyvolá dotazování a případně bude čekat v aktivní smyčce po dobu určenou v ip_low_latency_poll. Není proto těžké si představit, že na spoustě systémů citlivých na latenci se požadavek na rychlou odpověď týká jen některých spojení, zatímco u ostatních to není nutné. Dotazování na méně kritických spojeních by dokonce mohlo přivodit dodatečnou latenci u spojení, o která uživateli doopravdy jde. Takže i když si o to nikdo ještě nepožádal, nebylo by překvapením, kdyby se před začleněním objevila nová operace setsockopt() nastavující chování u daného socketu.

K začlenění určitě dříve nebo později dojde; správce síťové vrstvy Dave Miller na dřívější e-mail odpověděl Jen jsem chtěl říct, že se mi tato práce moc líbí. Ještě je nutné dořešit nějaké drobnosti a asi bude potřeba pár dalších kol revidování, takže se sockety s nízkou latencí do verze 3.11 možná nedostanou. Ale bylo by překvapivé, kdyby to trvalo výrazně déle.

       

Komentáře

[Petr Ježek]

Tak tohle oceňuji: Pokud by zswap vykazoval náhodné prodlevy ve zpracování komprimovaných dat a nebyl by označen jeko experimentální, pak by byl uživateli vypnut a zapomenut. Jelikož by jej bylo ale škoda a vývoj je nadějný, bude zařazen jako experimentální. Vzpomínáte na btrfs před dvěma lety? A pak že vývoj komunitního SW není "zákaznicky" odpovědný...

[petr_p]

Nebylo nedávno oznámeno, že volba enable experimental drivers bude z jádra odstraněna, protože jí stejně mají všichni zapnutou?

[Semo]

Neznamena tato volba iba zobrazenie moznosti zakompilovania jednotlivych driverov?

[Jiří J.]

O Linuxu se obecně traduje, že má jednu z nejrozsáhlejších a nejrychlejších podpor síťování, co existuje.

Hlavně že FreeBSD mu to bez problémů natře (od 50. minuty).

[Peter Fodrek]

Verte mi, ze som bol nastvany na svojho studenta(pre jeho laxny priustup k ulohe 6), ked som o low latency pollingu cital v anglickom ortiginale

ZADANIE BAKALÁRSKEJ PRÁCE

Evidenčné číslo: FEI-5402-51246 Autor práce: Róbert Bartusek Študijný program: Priemyselná informatika Študijné odbory: 5.2.14 automatizácia, 9.2.9 aplikovaná informatika Vedúci práce: Ing. Peter Fodrek, PhD. Miesto vypracovania: Ústav riadenia a priemyselnej informatiky (FEI STU)

Názov témy: Sieťový podsystém jadra Linux 4. Porovnajte výkon ovládačov využívajúcich polling a prístup cez IRQ 5. Navrhnite modifikácie architektúry s ohľadom na hard realtime so zachovaním soft realtime odozvy 6. Pokúste sa zmeny realizovať formou vlastného patchu, alebo začlenením od RT Preempt patchu, či hlavnej rady jadier

Dátum zadania bakalárskej práce: 20. 09. 2010 (od vtedy sa na temu mohli studenti prihlasovat)

zaujimave s ujeho vysledky, kde polling suverenne vyhral, lebo zatazenie CPU kleslo o 25% oproti IRQ pristupu.

Intel zacal skusat polling v ovladaci pre BSD v roku 2011, pre Linux v roku 2012 a od januara (ledna) 2013 je to prednastavena volby v ich ovladacoch pre Linux. Na BSD su vsak zaznamenane vacsie narast vykonu(obejemu prenesnych dat) ako v Linuxe, ale maximim pri pollingu je rovankae ako pri Linuxe. Takze skustocne je linuxova implementacia lepsia ako ta z BSD pri IRQ pristupe.

[Michal Kubeček]

Ještě je nutné dořešit nějaké drobnosti a asi bude potřeba pár dalších kol revidování, takže se sockety s nízkou latencí do verze 3.11 možná nedostanou. Ale bylo by překvapivé, kdyby to trvalo výrazně déle.

Vypadá to že napůl: ve 3.11 to asi bude, ale bez části implementující podporu v select()/poll(), která není ještě úplně v pořádku.

[stativ]

To dotazování síťového zařízení s nízkou latencí vypadá pěkně, ale co na to majitelé notebooků?

[Michal Kubeček]

Lze to vypnout přes sysctl a defaultně je to vypnuté:

low_latency_poll
----------------
Low latency busy poll timeout. (needs CONFIG_NET_LL_RX_POLL)
Approximate time in us to spin waiting for packets on the device queue.
Recommended value is 50. May increase power usage.
Default: 0 (off)

[stativ]

Díky, to je dobře.

[frr]

Po přečtení odkazovaného originálu zprávičky bych řekl, že právě Ktap je založený na bajtkódu - ačkoli i originál používá zájmeno "it" nejednoznačně. Tuhle moji hypotézu podporuje kapitola, kde se kompiluje a vkládá kernelový modul "Ktap VM". Je tam i hezký example.

Proč je tam ta zmínka o embedded světě, netušíte někdo? Má to něco společného s kompilací ze zdrojáků, binárními bloby a divnými licencemi? Nebo to nějak usnadňuje ladění na "headless" kompech bez VGA? Bez síťovky? Bez x86?

[asd]

KTAP vysiel vo verzii 0.1, nie 1.0..