Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování

25. 3. 2015 | Tadeáš Pelech | Jaderné noviny | 5841×

Stav vydání jádra. Tvůrce Linuxu chce, abychom se všichni uklidnili kvůli přestupné sekundě (Wired). Zlepšení výkonu linuxového síťování.

Obsah

• Stav vydání jádra
• Tvůrce Linuxu chce, abychom se všichni uklidnili kvůli přestupné sekundě (Wired)
• Zlepšení výkonu linuxového síťování

Stav vydání jádra

Aktuální vývojové jádro je 3.19-rc1, vydané dne 20. prosince – o jeden den dříve, než se dalo očekávat.

Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace.

Tvůrce Linuxu chce, abychom se všichni uklidnili kvůli přestupné sekundě (Wired)

Wired hovořil s Linusem Torvaldsem o možnostech další chyby spojené s přestupnou sekundou.

Vy všichni ostatní opravdu berte tu přestupnou sekundu jako záminku k uspořádání malého absurdního večírku pro své nejbližší přátele. Nasaďte si srandovní klobouky, nechte si natisknout transparent se slovy „Večírek soudné přestupné sekundy“ a pořádně se opijte. Jednou mrknete a bude po všem, ale aspoň budete mít další den kocovinu, která vám připomene tu slavnou, ale prchavou sekundu navíc.

Zlepšení výkonu linuxového síťování

Přicházejí 100Gb síťové adaptéry, konstatoval Jesper Brouer ve své přednášce na minikonferenci jádra LCA 2015 (snímky [PDF]). Řízení těchto adaptérů v jejich plné podporované rychlosti bude pro linuxové jádro významnou výzvou; řešení tohoto problému je náplní jeho současné i budoucí práce. Dobrou zprávou je, že linuxové síťování se díky tomu trochu zrychlilo – i když je stále nutné vyřešit některé problémy.

Výzva

Jak síťové adaptéry zrychlují, doba mezi pakety (tj. čas, ve kterém musí jádro zpracovat každý paket) se zkracuje. U současných 10Gb adaptérů je to 1 230 ns mezi dvěma 1538bajtovými pakety. Přenosová rychlost 40 Gb/s tuto dobu výrazně snižuje na 307 ns. 100 Gb/s tento problém přirozeně zhoršuje, protože zkracuje čas na paket na zhruba 120 ns; v tomto případě rozhraní zpracovává 8,15 milionů paketů za sekundu. To nenechává příliš času na to, aby systém zjistil, co se kterým paketem provést.

Co ale máte dělat, pokud – jako většina z nás – nemáte na hraní 100Gb adaptér? Místo něj použijete 10Gb adaptér s malými rámci. Nejmenší ethernetový rámec, který lze odeslat, je 84 bajtů; podle Jespera je u 10Gb adaptéru mezi pakety nejmenší velikosti prodleva 67,2 ns. Systém, který se s takovou zátěží dokáže vyrovnat, by měl být schopen rozumně zvládat 100Gb sítě, až budou k dispozici. Ale vyrovnat se s takovou zatížení je těžké: na 3GHz procesoru máte pro zpracování každého paketu k dispozici pouze asi 200 cyklů procesoru. To, jak poznamenal Jesper, není mnoho.

Jádro se tradičně s tímto druhem síťových intenzivních zatížení nevyrovnává nejlépe. To vedlo ke vzniku řady síťových implementací mimo hlavní strom, které zásobník síťové vrstvy jádra zcela obcházely. Poptávka po takových systémech naznačuje, že jádro nepoužívá hardware optimálně; implementace mimo hlavní strom může řídit adaptéry plnou dostupnou rychlostí z jediného procesoru, což jádro hlavní větve příliš nezvládá.

Problém je podle Jespera v tom, že vývojáři jádra se zaměřovali na škálování na velký počet jader. Během toho se jim dařilo skrývat regrese efektivity na jedno jádro. Zásobník síťové vrstvy v důsledku toho funguje dobře pro více zátěží, ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací doby. Jádro dnes dokáže předávat pouze něco mezi 1 M a 2 M pakety na jádro za sekundu, zatímco některé z nezávislých alternativ se blíží k rychlosti 15 M paketů na jádro za sekundu.

Časová režie

Pokud budete chtít tento druh problému řešit, musíte si důkladně posvítit na režii na každý krok ve zpracování paketu. Tak například řešení neúspěšného přístupu do mezipaměti na Jesperově 3GHz procesoru trvá asi 32 ns. Stačí tedy dva neúspěšné přístupy k vyčerpání celého času vyhrazeného zpracování paketu. Vzhledem k tomu, že vyrovnávací paměť soketů („SKB“) zabírá na 64bitovém systému čtyři řádky mezipaměti a že velká část SKB je zapsána během zpracování paketů, je první část problému jasná – čtyři neúspěšné přístupy do mezipaměti by spotřebovaly mnohem víc času, než je k dispozici.

Mimo to, použití prefixu x86 LOCK pro atomické operace trvá asi 8,25 ns. V praxi to znamená, že nejkratší cyklus uzamčení/odemčení trvá něco přes 16 ns. V takovém časovém limitu tedy není dost místa pro hodně zamykání.

K tomu se přičítá doba potřebná na provedení systémového volání. V systému s aktivní ochranou SELinux a auditováním to zabere lehce přes 75 ns – tedy celou vymezenou dobu. Deaktivace auditování a SELinuxu zkracuje potřebný čas těsně pod 42 ns, což je lepší, ale i tak je to značná část celkového času. Existují způsoby, jak tuto režii vyrovnat v rámci několika paketů; mezi ně patří systémová volání jako sendmmsg(),recvmmsg(),sendfile() nebo splice(). V praxi to ovšem podle něj nefunguje tak dobře, nezjistil ale prý důvod. Christoph Lameter z publika poznamenal, že uživatelé závislí na čekací době mají tendenci používat mechanismus InfiniBand „IB verbs“.

Jesper se potom zeptal, jak je možné, že řešení obcházející jádro dosahují lepších výsledků. Zdá se, že klíčem je dávkové zpracování operací, předběžná alokace a předběžné načítání zdrojů. Tato řešení pracují v režimu CPU-local a předcházejí tak zamykání. Také je důležité zmenšit metadata paketů a snížit počet systémových volání. Pomůžou také rychlejší datové struktury optimalizované pro vyrovnávací paměť. Ze všech těchto technik je nejdůležitější dávkové zpracování operací. Režii, která je nepřijatelná na úrovni paketů, lze lépe zvládnout, pokud se projevuje jednou za desítky paketů. 16ns zamykání na paket je příliš; pokud se současně zpracuje 16 paketů, toto zatížení klesne na 1 ns na paket.

Zlepšení dávkového zpracování

Proto není divu, že Jesperova práce se zaměřuje na zlepšení dávkového zpracování v síťové vrstvě. To zahrnuje práci na hromadném přenosu TCP, o které jsme zde informovali v říjnu; podrobnosti o tom, jak všechno funguje, najdete v tomto článku. Stručně řečeno, jedná se o mechanismus pro informování síťových ovladačů o tom, že existují další pakety čekající na přenos; to umožní ovladači odložit nákladné operace, dokud nejsou všechny tyto pakety zařazeny do fronty. V případě nasazení tohoto mechanismu dokáže jeho systém přenášet 14,8 M paketů za sekundu – tedy, pokud se stále dokola posílá stále jeden malý paket.

Nejsložitější podle něj je přidání dávkově pracujících API do zásobníku síťové vrstvy bez zvýšení latence systému. Latence a propustnost si velmi často konkurují; tady je cílem optimalizace obou. Obzvlášť těžké je odolat spekulacím se zpožděním přenosu – vsadit na to, že se brzy objeví další paket. Takové triky často zlepší výsledky benchmarků, ale jsou méně vhodné pro skutečné zatížení.

Dávkové zpracování může – a mělo by – probíhat v několika vrstvách zásobníku. Vhodným místem pro dávkové zpracování je například systém disciplín ukládání do fronty („qdisc“); při řazení do fronty už tak jako tak dochází ke zpoždění. V nejlepším případě vyžaduje kód qdisc v současnosti šest operací LOCK na paket – 48 ns čisté režie uzamykání. Celková režie na řazení paketů do front je 58–68 ns, většinu času tedy spotřebují operace zamykání. Jesperova práce spočívala v přidání dávkového zpracování, aby se režie rozložila na několik paketů; to ale funguje jen v případě, že taková fronta paketů existuje.

Nominální rychlý průchod kódem qdisc nastává, když neexistuje žádná fronta; v takových situacích mohou být pakety často předány přímo do síťového rozhraní bez řazení do fronty. V současnosti takové pakety provází režie všech šesti operací LOCK. Podle něj by to mělo jít lépe. Subsystém qdisc bez zámků by mohl odstranit téměř veškerou režii na řazení paketů do fronty. Jesper má testovací implementaci, na které předvádí, čeho lze dosáhnout; eliminace minimálně 48ns režie za to podle něj stojí.

Zatímco výkon odesílání podle něj nyní vypadá poměrně dobře, zpracování příjmu by se stále mohlo ještě trochu zlepšit. Vysoce vyladěná konfigurace může dosáhnout rychlosti maximálně asi 6,5 M paketů za sekundu – a v takových případech se pakety jednoduše zahazují po příjmu. Probíhají určité práce na optimalizaci průběhu příjmu, které toto maximum zvýší na něco přes 9 M paketů za sekundu. Problém je ale v benchmarku: ten neukazuje režii na interakce se subsystémem správy paměti.

Správa paměti

A ukazuje se, že tato interakce je velmi slabá. Přenosová cesta zásobníku síťové vrstvy má podle všeho některé vzorce chování, které nevedou k nejlepšímu způsobu práce alokátorů tabulek. Přijímací kód může přidělit prostor až pro 64 paketů současně, zatímco přenosová cesta může uvolňovat dávky až po 256 paketech. Tento vzorec podle všeho poměrně zpomaluje především alokátor SLUB. Jesper provedl nějaké mikrobenchmarky a zjistil, že jedno volání kmem_cache_alloc() následované voláním kmam_cache_free() vyžaduje asi 19 ns. Pokud se ale provádělo 256 přidělení a uvolnění, tato doba narostla na 40 ns. V zásobníku síťové vrstvy v reálném prostředí, kde současně probíhají další procesy, může ale režie přidělování a uvolňování narůst ještě více, na 77 ns – více než celý vyhrazený časový rámec.

Proto Jesper dospěl k závěru, že je nutné kód správy paměti vylepšit nebo nějakým způsobem zcela obejít. V rámci testů druhé z variant implementoval subsystém nazvaný qmempool; ten provádí hromadné operace přidělování a uvolňování bez zamykání. Díky qmempool byl schopen ušetřit 12 ns v jednoduchých testech a až 40 ns v testech předávání paketů. Existuje celá řada způsobů zrychlení používaných v qmempool, navrch má ale dávkové zpracování operací.

Jesper skončil tím, že uvedl, že qmempool implementoval jako jakousi provokaci: chtěl ukázat, co je možné, a přimět vývojáře správy paměti, aby s tím něco udělali. Odpověď z tábora správy paměti následovala v další přednášce, která bude zveřejněna samostatně.

[Editor by chtěl poděkovat linux.conf.au za financování jeho cesty na tuto akci.]

       

Komentáře

[Michal Kubeček]

Překládat "socket buffer" jako "vyrovnávací paměť soketů" je extrémně matoucí. A na ten "zásobník síťové vrstvy" už byl překladatel upozorněn dříve (možná i víc než jednou).

[Nikola Ciprich]

v překladu by se chybky našly, ale rozhodně se to lepší a jinak byl aspoň pro mně tento díl opravdu zajímavy.. dík!

[Václav HFechs Švirga]

+1

[Conscript89]

+1

[pet]

+1

Omlouvám se za to neoblíbené +1, ale překladatel (na rozdíl od mne) vládne angličtinou a má čas to překládat a já jsem mu za to vděčný a čas od času se to snažím dát najevo. Může si mé poděkování domyslet pod každým dílem kam je běžně nepíši. Díky.

[Petr Ježek]

Přesně tak. drobné chybky si většina z nás sama opraví a entropie může být zašlápnuta. Zaráží mne pouze, že se málokdo dosud zamýšlel nad režií na paket a zapomněl, proč se data v dřevních dobách posílala dávkově. Ignorance historie vede pouze k opakování starých známých chyb...

[Michal Kubeček]

Hlavní důvod je IMHO to, že problémy s výkonem se obvykle řeší až ve chvíli, kdy někoho začnou opravdu trápit. V situaci, kdy na svém počítači i s MTU 1500 a povypínaným LRO/GRO/TSO/GSO vytáhnu z netperfu 3.3 Gb/s a jakmile jedno z toho vrátím zpátky, tak ten 10Gb/s ethernet téměř nasytím, není až tak překvapivé, že dokud se 40Gb/s ethernet nestal realitou všedního dne (aspoň pro někoho) a 100Gb/s se neobjevil na horizontu, potřeba optimalizovat zpracování paketu "na krev" nebyla dost velká, aby vývojáři kvůli ní riskovali regrese.

[Jendа]

ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací doby

To je workload? Přeložil bych to jako typy zátěží.

[ncweohfnow]

A co nealokovat pamat vobec? Pristup ako pri http://fasterjava.blogspot.sk/2013/04/disruptor-example-udp-echo-service-with.html

[Bystroushaak]

Zajímalo by mě, proč není zamykání řešené přímo hardwarem. Když to žere docela dost prostředků, tak by bylo fajn mít pro to hardwarovou podporu, ne?

[Michal Kubeček]

K tomu by bylo potřeba si nejdřív ujasnit, o jakém zamykání je vlastně řeč. V tomto kontextu se mluví o atomických operacích a s tím souvisejícím LOCK (instrukčním) prefixem, což je hardwarová záležitost.

[Petr Ježek]

Následně je třeba si ujasnit, jaký kód má mít "vlastní židli" (být operačně atomický). Odhaduji, že takového kódu mnoho není a že jde o nezamýšlenou atomizaci. Ostatně nenárůst režie na dávku paketů oproti "single" dost jasně říká, kde hledat problém.

[Jendа]

Řešené je, ale řekl bych, že trvá, než to projde k ostatním jádrům a než si upraví cache(?).

[Snehuliak]

Preco konecne nezvysit MTU?

[Michal Kubeček]

MTU zvýšit můžete, koneckonců už většina gigabitových karet podporuje MTU přinejmenším 9000. Ale to řeší jen část problému. Jednak jsou tu featury typu TSO/GSO/LRO/GRO, díky kterým nemusí být zase až tak důležité, jak velké pakety běhají "po drátě", jednak ne zdaleka ne všechna komunikace je TCP přenos velkých datových bloků, je řada protokolů a aplikací, kde větší pakety stejně posílat nejde nebo to nemá smysl.

[Petr Ježek]

Protože to neřeší problém tam, kde vznikl.

[pc2005]

Páni 100Gb, kde jsou ty časy, když jsem rozběhával 115200kbps UART se SLIPem . BTW to se už skoro dá implementovat raw video-out over ethernet ne?

[Petr Tomášek]

záleží na rozlišení