abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 02:00 | Nová verze

Turris OS, operační systém pro síťová zařízení Turris, byl vydán v nové major verzi 5.0. Vychází z OpenWrt 19.07.3. Podrobnosti na GitLabu.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Nová verze

Byla vydána verze 1.44.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 0
včera 17:00 | Bezpečnostní upozornění

Nedávno byla vydána nová verze 9.4.6 nástroje pro řízení a správu IT zařízení a služeb GLPI (Wikipedie). Opraveno bylo několik bezpečnostních chyb. Například také SQL injection CVE-2020-11032 aneb email z ';-- Have I Been Pwned? dokáže smazat celý ticket systém.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Zajímavý článek

MojeFedora.cz informuje, že Firefox 77 pro Fedoru přináší akceleraci videa. Firefox 77 pro Fedoru obsahuje patche, které konečně přináší podporu pro VA-API, tedy hardwarovou akceleraci videa. Podpora pro VA-API momentálně funguje pouze na Waylandu.

Ladislav Hagara | Komentářů: 4
včera 12:00 | Pozvánky

Sdružení CESNET dnes opět po roce pořádá jednodenní seminář věnovaný internetovému protokolu IPv6. Tentokrát on-line a s názvem Svět bez IPv4. K dispozici jsou také prezentace a záznamy přednášek z loňského roku.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Nová verze

Byla vydána nová stabilní verze 2.83 svobodného 3D softwaru Blender. Přehled novinek v oznámení o vydání a na YouTube. Jedná se o první verzi Blenderu s prodlouženou dvouletou podporou (LTS).

Ladislav Hagara | Komentářů: 4
včera 07:00 | Zajímavý článek

Jim Salter v recenzi pro Ars Technica srovnává novou generaci notebooků Dell XPS 13 s MS Windows 10 a Ubuntu (model „Developer Edition“). V obou případech naráží na problémy s výchozími ovladači: Wi-Fi Killer na Windows, chybná detekce ovladačů (audio čipu a Wi-Fi) od Dellu v Ubuntu.

Fluttershy, yay! | Komentářů: 12
3.6. 16:22 | Nová verze

Byla vydána verze 2.2 svobodné federalizované platformy pro sledování a sdílení videí, alternativy YouTube s podporou P2P, PeerTube (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Přispět lze na vývoj verze 3. V plánu je například podpora živého přenosu (live streaming). Za vývojem PeerTube stojí nezisková organizace Framasoft snažící se mimo jiné nahradit svými svobodnými Frama službami služby společnosti Google (De-google-ify Internet). Bohužel ale musí některé své služby omezovat.

Ladislav Hagara | Komentářů: 8
3.6. 07:00 | Komunita

Lenovo oznámilo, že bude certifikovat všechny své pracovní stanice řady ThinkStation a ThinkPad P pro Linux, konkrétně pro linuxové distribuce Red Hat Enterprise Linux a Ubuntu LTS. Doteď byly certifikovány pouze konkrétní modely.

Ladislav Hagara | Komentářů: 14
3.6. 00:44 | Nová verze

Oficiálně byl vydán Devuan Beowulf 3.0.0. Přehled novinek v poznámkách k vydání. Kódové jméno Beowulf je podle planetky s katalogovým číslem 38086. Příští verze 4.0.0 bude Chimaera. Devuan (Wikipedie) je fork Debianu bez systemd.

Ladislav Hagara | Komentářů: 0
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (35%)
 (19%)
 (5%)
 (12%)
 (9%)
 (5%)
 (15%)
 (23%)
Celkem 74 hlasů
 Komentářů: 2, poslední včera 19:05
Rozcestník

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

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

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

link

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)

link

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í

link

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

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

25.3.2015 08:28 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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 avatar 25.3.2015 11:11 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Palkovice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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!
Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
25.3.2015 14:48 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
+1
Baník pyčo!
Conscript89 avatar 26.3.2015 09:33 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
+1
I can only show you the door. You're the one that has to walk through it.
27.3.2015 15:06 pet
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
+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.
30.3.2015 10:17 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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...
Archlinux for your comps, faster running guaranted!
30.3.2015 10:52 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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а avatar 26.3.2015 03:20 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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ěží.
5GBioShield | "Gravitace vyvrácena pokusem" | Tvoje složka chrání mě, moje složka chrání tebe.
26.3.2015 09:48 ncweohfnow
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
A co nealokovat pamat vobec? Pristup ako pri http://fasterjava.blogspot.sk/2013/04/disruptor-example-udp-echo-service-with.html
Bystroushaak avatar 27.3.2015 10:09 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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?
27.3.2015 10:27 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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.
30.3.2015 10:27 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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.
Archlinux for your comps, faster running guaranted!
Jendа avatar 27.3.2015 13:40 Jendа | skóre: 76 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
Řešené je, ale řekl bych, že trvá, než to projde k ostatním jádrům a než si upraví cache(?).
5GBioShield | "Gravitace vyvrácena pokusem" | Tvoje složka chrání mě, moje složka chrání tebe.
28.3.2015 02:22 Snehuliak
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
Preco konecne nezvysit MTU?
29.3.2015 03:07 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
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.
30.3.2015 10:27 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
Protože to neřeší problém tam, kde vznikl.
Archlinux for your comps, faster running guaranted!
29.3.2015 04:08 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
Páni 100Gb, kde jsou ty časy, když jsem rozběhával 115200kbps UART se SLIPem :-D. BTW to se už skoro dá implementovat raw video-out over ethernet ne? :-D
Petr Tomášek avatar 30.3.2015 21:45 Petr Tomášek | skóre: 38 | blog: Vejšplechty
Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 1. 2015: Zlepšení výkonu linuxového síťování
záleží na rozlišení :-D
multicult.fm | monokultura je zlo | welcome refugees!

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.