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

4. 11. 2014 | Tadeáš Pelech | Jaderné noviny | 2702×

Aktuální verze jádra: 3.17. Citáty týdne. Repozitář Git pro jádro Fedory. Začleňovací okno verze 3.18 – 1. část. Hromadný přenos síťových paketů.

Obsah

• Aktuální verze jádra: 3.17
• Citáty týdne
• Repozitář Git pro jádro Fedory
• Začleňovací okno verze 3.18 – 1. část
• Hromadný přenos síťových paketů

Aktuální verze jádra: 3.17

Jádro 3.17 vyšlo 5. října (oznámení), takže v době vzniku tohoto textu nebylo k dispozici žádné vývojové jádro. Byl zahájen příjem oprav do hlavního repozitáře pro vývojový cyklus 3.18; podrobnosti o tom, co již bylo začleněno, si přečtěte v samostatném článku níže.

Stabilní aktualizace: verze 3.16.4 (oznámení), 3.14.20 (oznámení) a 3.10.56 (oznámení) byly vydány dne 5. října. Aktualizace verzí 3.10.57 (oznámení), 3.14.21 (oznámení) a 3.16.5 (oznámení) jsou v době vzniku tohoto textu v procesu kontroly, lze je očekávat nejdříve 9. října.

Citáty týdne

Poznamenejte si, že jsem zmatený. A když jsem zmatený, nezavádím opravy.

– Linus Torvalds (odkaz)

Ne, nezmátlo to mě – zmátlo to vás, abyste si mysleli, že jsem zmatený já.

– Borislav Petkov (odkaz)

Jedna věc, kterou jsem se za posledních 16 let naučil při práci v komunitě open source, je, že lidé, kteří tvrdí, že vědí všechno lépe než všichni ostatní, nepatří k těm, ke kterým by se společenství chovalo dobře. Ale ti, kteří jsou ochotní spolupracovat a naslouchat jiným předtím, než se snaží prosadit své metody, jsou vítáni s otevřenou náručí.

– Steven Rostedt (odkaz)

Repozitář Git pro jádro Fedory

Josh Boyer popisuje nový repozitář, který připravil pro jádro Fedory. „Myslel jsem, že samotný strom by mohl být ostatním taky užitečný. Jako poslední krok každé aktualizace jsem přidal vygenerované konfigurační soubory jádra, které jsme použili k překladu jádra. Naše nastavení konfigurace v balíčku je pro lidi, kteří s ním nepracují denně, poněkud matoucí a není úplně jasné, jak všechny díly zapadají do sebe. Takhle je všechny máme na jednom místě.“

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

Linus uvedl svůj záměr dát si týden pauzu od začleňování oprav před otevřením začleňovacího okna oprav verze 3.18 kolem 12. října. Přesto se nějakým způsobem, když se nikdo nedíval, odněkud v hlavním úložišti objevilo pár tisíc (konkrétně 2 936) změnových sad. Jako první byly vybrané opravy týkající se zdrojových kódů ovladačů (včetně stromu staging), protlačilo se mezi ně ale i několik dalších položek.

Mezi začleněné změny viditelné pro uživatele zatím patří:

• Architektura arm64 nyní podporuje kompilaci just-in-time programů rozšířeného filtru paketů Berkeley (eBPF).
• Kryptografická vrstva získala podporu operací ve více zásobnících. Podstatou je použití paralelních hardwarových operací k provádění stejných transformací v několika vyrovnávacích pamětech současně. Ve verzi 3.18 je implementace algoritmu SHA1, která tuto funkci může využít.
Server NFS nyní podporuje operaci NFS 4.2 „SEEK umožňující implementaci možností Linuxu „SEEK_HOLE a SEEK_DATA lseek().
• Systém souborů F2FS podporuje atomické zápisy (kde je série operací úspěšná nebo neúspěšná jako celek) pomocí specifických operací systému souborů „ioctl(). F2FS také získal podporu operace „FITRIM (discard).
• Podpora nového hardwaru zahrnuje:
• Lidský vstup/výstup: Dotykové řadiče PenMount 6000, haptické řadiče TI DRV260X a DRV2667, tlačítka napájení TI Palmas a haptické řadiče MAXIM MAX77693.
• Různé: Řídicí jednotky Freescale i.MX21, řadiče Qualcomm APQ8084, řadiče Broadcom BCM53xx SPI, generátory skutečných náhodných čísel APM X-Gene, převodníky D/A Maxim MAX5821, akcelerometry Bosch BMC150, tříosé gyroskopické snímače Bosch BMG160, převodníky A/D (ADC) Texas Instruments ADC128S052, ADC Rockchip SARADC, snímače okolního světla Dyna Image AL3320A, LPC na 4 UART Fintek F81216A, sériové porty Amlogic Meson a sériové porty Mediatek.
• Regulátory: Regulátory Dialog Semiconductor DA9213, regulátory napětí HiSilicon Hi6421 PMIC, regulátory Intersil ISL9305, regulátory Qualcomm RPM, regulátory Maxim 77802, regulátory výkonu Rockchip RK808 a regulátory napětí Ricoh RN5T618.
• USB: Řadiče periferií Xilinx USB2, řadiče ST Microelectronics OHCI/EHCI, PHY USB Renesas R-Car 2. generace, picoPHY USB2 STMicroelectronics, vysílače USB STMicroelectronics STiH41x, řadiče National Instruments USB-6501 a detektory příslušenství portů USB Richtek RT8973A.

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

• Bylo začleněno několik oprav „zeštíhlení“ jádra pro ty, kteří se snaží sestavit co možná nejmenší jádro. Ve verzi 3.18 je možné nakonfigurovat tabulku popisující bity možností procesoru a systémová volání „madvise() a „fadvise().
• Parametry modulu lze definovat s novým příznakem „unsafe“; při každém pokusu o změnu takového parametru bude generováno upozornění a znečištěno jádro. K nastavení těchto parametrů lze použít makro „module_param_unsafe().
• Moduly jádra nyní může systém sestavení nainstalovat v komprimované podobě.
• Jádro ovladače má nový mechanismus „device coredump“, který lze použít k získání výpisů paměti jádra a dalších diagnostických informací z periferních zařízení. Má sloužit jako pomůcka pro ladění firmwaru.

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.

Hromadný přenos síťových paketů

Jedním z klíčů k dobrému výkon v současných systémech je dávkové zpracování – provedení velkého množství práce vzhledem k daným fixním nákladům. Pokud je například potřeba získat zámek pro provedení jedné jednotky práce v určitém subsystému, provedení více jednotek práce po dobu platnosti zámku sníží celkovou režii systému. Velká část práce na škálovatelnosti vykonané v posledních letech jistým způsobem souvisí se zvýšením dávkování tam, kde je to možné. Některé nedávné změny v síťovém subsystému ukazují, že i tam může dávkové zpracování zlepšit výkon.

Při každém přenosu paketu v síti je nutné provést posloupnost operací. Mezi ně patří získání zámku pro frontu odchozích paketů, předání paketu ovladači, vložení paketu do přenosové fronty zařízení a zadání příkazu zařízení, aby začalo vysílat. Některé z těchto operací ze své podstaty probíhají na úrovni paketů, ale jiné ne. Například zámek fronty by se mohl získávat pro přenos více paketů a vydání příkazu, aby zařízení zahájilo vysílání, může být opravdu nákladné. Může zahrnovat hardwarové operace nebo – v některých systémech – volání hypervizoru.

Často se stává, že pokud je k odeslání určen jeden paket, mohou ve frontě čekat další; provoz v síti může být z podstaty nárazový. Proto vypadá rozumně, aby se síťová vrstva snažila co nejdříve rozdělit fixní náklady na zahájení přenosu paketů na libovolný počet paketů. Takové dávkové zpracování používají některé techniky, jako je snižování zátěže segmentace (kde síťové rozhraní rozdělí velké bloky dat do paketů). Ale v současných jádrech, pokud má síťová vrstva připravenou sadu paketů, odešle je pomalým způsobem, jeden po druhém.

Tato situace se začne měnit ve verzi 3.18, pokud bude začleněn relativně malý počet změn. Vezměme funkci exportovanou řadiči, která má odeslat paket nyní:

 netdev_tx_t	(*ndo_start_xmit) (struct sk_buff *skb, struct net_device *dev);

Tato funkce vezme paket odkazovaný pomocí „skb a odešle jej pomocí zadaného „dev. Každé volání je nezávislá operace se všemi souvisejícími fixními náklady. Původně bylo pro verzi 3.18 v plánu určit novou funkci, kterou by mohly poskytnout ovladače:

 void (*ndo_xmit_flush)(struct net_device *dev, u16 queue);

Pokud by ovladač tuto funkci poskytoval, ohlašoval by síťové vrstvě, že je připraven na dávkové přenosy (a dokáže jich využít). V takovém případě by síťový zásobník mohl pomocí více volání „ndo_start_xmit() zařadit pakety do fronty k odeslání; řadič by je přijal, ale ve skutečnosti by operaci přenosu nezahájil. Na konci sekvence by provedl volání „ndo_xmit_flush()“, kterým by označil konec; teprve tehdy by došlo k zahájení skutečného hardwarového přenosu.

Objevily se ovšem obavy, že uvedení další funkce nepřímého volání do přenosové cesty by také příliš navýšily režii, proto byla tato konkrétní funkce vyřazena v podstatě okamžitě po svém zařazení do repozitáře net-next. Místo toho získala struktura „sk_buff novou logickou proměnnou s názvem „xmit_more“. Pokud má tato proměnná hodnotu True, přichází více paketů a řadič může odložit zahájení hardwarového přenosu. Tato proměnná vyžaduje další volání funkce pro zpřístupnění potřebných informací ovladači, kterému se mohou hodit.

Tento mechanismus, přidaný Davidem Millerem, umožňuje dávkové zpracování. Pro podporu dávkového zpracování bylo upraveno několik ovladačů, ale David nezměnil síťový zásobník, aby dávkové zpracování skutečně prováděl. Tu práci dostal na starost Jesper Dangaard Brouer, jehož opravy pro podporu hromadného vyvolání z fronty bylo také začleněno do verze 3.18. Tato práce je také omezena; konkrétně bude fungovat pouze se způsoby řazení do fronty, které mají jedinou přenosovou frontu.

Jesperova změna je celkem jednoduchá: v situaci, kdy se paket odesílá, se síťová vrstva pokusí vyslat sérii paketů v rámci jediného uzamčení fronty. K nastavení horního limitu objemu dat, která lze odeslat současně, lze použít mechanismu bajtového omezení fronty. Při dosažení tohoto limitu (nebo když je spotřebována celá zásoba paketů), bude hodnota skb->xmit_more nastavena na hodnotu False a pakety budou odeslány.

Erica Dumazeta při prohlídce sady oprav napadlo, že by bylo možné zajít ještě trochu dále: proces ověřování paketů pro přenos by se mohl přesunout zcela mimo zámek fronty, což by v systému zvýšilo možnosti paralelního zpracování. Výhody výsledné opravy označil Eric za báječné: drátová přenosová rychlost plných 40 Gb/s dokonce i se snížením zátěže segmentace. Tato oprava byla také samozřejmě přijata do stromu net-next pro slučovací okno verze 3.18.

Se vším všudy jde o relativně malé změny. Ale malé změny mohou mít velký vliv, pokud se provedou na správných místech. Tyto malé změny by měly pomoci dále zvýšit rychlost zásobníku síťové vrstvy verze 3.18.

       

Komentáře

[Petr Ježek]

Lennartovi by se hodila Stevenova šestnáctiletá zkušenost. Hosana paketování při nižší režii.

[Xerces]

Jestli on tu zkušenost nemá převážně od něj.

[ebik]

Tak v překladu citátu Borise Petkova se nějak zaměnil podmět to s podmětem já. Že je pak význam poněkud jiný snad nemusím dodávat.

[Tadeáš Pelech]

Pravda, díky za upozornění.

[ebik]

... přenosová rychlost pomocí vodičů plných 40 Gb/s dokonce i v případě snižování zátěže segmentace. ...

Pooomoooooc!

[deda.jabko]

Kolíkové řídicí jednotky

...jsou taky kvalitni

[Bystroushaak]

Ví někdo o co se jedná? Osobně jsem na to nějak nebyl schopný přijít, napadlo mě jen vačkové CNC, ale to asi nebude ono.

[ebik]

Stačí číst originál:

pin controlling unit je totiž typicky obyčejný řadič GPIO

[Bystroushaak]

Stačí číst originál

Na něj jsem během rychlého průzkumu nenašel odkaz.

[ebik]

Jo, on je graficky na takovém místě, na kterém člověk čeká reklamu/selfpromo/ostatní věci nesouvisející s článkem. Takže vím, že mám hledat za koncem článku a většinou ho najdu. (V normálních publikacích (které se snaží tvářit seriózně) jsou související odkazy graficky ve stejném prostoru jako článek.)

[Bystroushaak]

Ha, tak jsem našel, teď když jsi psal že je na konci. To mi ovšem naprosto odfiltroval mentální spamfiltr.

[Aleš Kapica]

Nejspíš . Já bych se tedy spokojil s pouhým "řídící jednotky s Freescale i.MX21"

[Tadeáš Pelech]

Souhlasím, upraveno.

[little.owl]

To me take dostalo.

[Michal Kubeček]

Obvykle funguje otrocký překlad zpátky do angličtiny, ale tuhle větu jsem prostě nedal a po přečtení originálu mi spadla čelist nad tvořivostí překladatele.

[little.owl]

Taky jsem musel videt original - alespon jsem se zasmal, takze diky autorovi.

[Lol Phirae]

Příloha:

• lokalizovany_instalator.png (30429 bytů)

Vy s tím překladem naděláte... Viz příloha.

[frr]

Zahlédl jsem zmínku ohledně F81216A, což vzbudilo mou zvědavost. K čemu explicitní podpora/ovladač?

Tenhle čtyřnásobný UART na LPC se vůči OS tváří jako čtyři generické UARTy 16C550A na klasických ISA adresách a IRQ (případně neklasických, pokud si tak švába nastavíte Vy nebo Váš BIOS). Navíc bývá BIOSem reportován skrz ISAPnP, takže Linux UARTy odjakmrtva i bezpečně autodetekuje (bez ISAPnP by stačil setserial).

Toho Finteka zná tuším taky user-space SuperIOtool - ale ten je dobrý tak na základní detekci (že je v systému skutečně Fintek, což může být zajímavá informace), případně na dump registrů (dost k ničemu).

Tenhle Fintek je zajímavý tím, že patří do skupiny UARTů, které umí hardwarově řídit half-duplex RS485 - alternativní funkcí pinu RTS. Motherboard samozřejmě musí ještě obsahovat odpovídající transceiver (analogový level shifter), případně lze pořídit snad i externí konvertor, třeba Advantech ADAM-4520 (ale pak to hardwarové řízení přímo v UARTu trochu ztrácí svou jedinečnost, protože ADAM si to umí ošetřit sám). => čili napadlo mě, že možná někdo přidal driver, který ví o schopnostech směrem k RS485 u tohoto LPC UARTu.

A skutečně, jedná se o driver (extra modul), který ví o RS485 v rámci švábu Fintek. Což je na jednu stranu chvályhodné, na druhou stranu zrovna tenhle Fintek má flagy pro nahození podpory RS485 umístěny natolik "stranou", že do nich nedrbe standardní UART driver 8250.c v Linuxu ani ve Windows, takže jakmile si jednou nastavíte podporu RS485 v BIOSu, tak už do toho nastavení v rámci OS nepotřebujete drbat. => není důvod mít pro to driver, snad jen s výjimkou hypotetického defektního motherboardu, který by měl podporu RS485 v hardwaru (transceiver onboard), ale chyběla by konfigurace v BIOS Setupu (nebo by byla vadná). I tak by to patrně šlo řešit z user space, přímým přístupem povoleným skrz ioperm().

V tomto ohledu jsou speciálním případem UARTy OX16C950 a kompatibilní (celé oxfordí portfolio), které naopak trpí tím, že jim vanilkový driver v Linuxu flagy okolo RS485 resetuje při každém volání open() jak slon v porcelánu - takže bez patche na vanilkovém kernelu se s RS485 nehnete.

Při čtení toho nového ovladače pro Fintek jsem si všiml, že se odkazuje na nějaký zajímavý struct a IOCTL týkající se RS485, které sám nedeklaruje.

Žeby už měl kernel podporu pro RS485 ve vanilce uvnitř? Žeby to někdo prosadil, po patnácti nebo kolika letech, přestože to Linus nemá ve svém notebooku, přestože UARTy dávno přešly v kancelářském hardwaru do "trvalé zombie fáze", přestože kompletní rodina Oxford 16xxx95x je už asi půl roku EOL?

Prozkoumal jsem nějaké výskyty těch věcí:
Klíčová slova:
TIOCSRS485
struct serial_rs485
Soubory:
include/uapi/linux/serial.h (10/2012)
include/uapi/asm-generic/ioctls.h (vznikl 10/2012, těžko říct zda TIOCSRS485 je ještě starší)
Documentation/serial/serial-rs485.txt (12/2010)
Documentation/devicetree/bindings/serial/rs485.txt (10/2011)

Závěr:
Zdá se, že je to zas jen další výkřik do tmy. struct serial_rs485 nemá dostatek flagů, aby popsal chování 16C950 a příbuzných. Zmíněná "vanilková podpora" žije trochu bokem v headerech UAPI, což vypadá jako dost platform-specific věc, pro konkrétní ne-x86 platformy (tuším nějaký ARM nebo MIPS). Využívají to asi čtyři drivery pro obskurní on-chip UARTy uvnitř všelijakých SoCů.
Generický 8250.c dál obsahuje ten řádek nebo dva uvnitř open(), který torpéduje podporu RS485 v 16C950 a spol. - takže kdo to chce používat, ten se bez patche nadále neobejde.

Zažil jsem několik případů v různých modelech x86 hardwaru, kde Fintek F81216 různými vynalézavými způsoby buď hnil/havaroval po nějaké době běhu (začal mršit data), případně neudržel stolici hned po startu (potkával se motor s motorem na LPC proti south bridgi nebo co). Situace, kdy ho k vadnému chování ponoukl krátký pulz (mnohem kratší než jeden bit) přijatý z RS485, byla relativně nejpochopitelnější, přesto v průmyslovém použití na RS485 není takové chování přijatelné - UART toto musí ustát. Tenhle prašivý Fintek se dál a dál prodává a výrobci motherboardů ho používají patrně především proto, že je superlevný, možná levnější než srovnatelný (a 100% solidní) Winbond/Nuvoton, navíc Winbond historicky dlouhá léta kašlal na podporu RS485, takže mu Fintek pytlačil ve skulině trhu, kterou tvoří průmysloví zákazníci.

Naopak tradiční 16C950, původně vyráběný firmičkou Oxford, kterou před pár lety spokl žraloček PLX, po všech stránkách super kvalitní UART pro průmyslové použití, je už pár měsíců u PLX oficiálně EOL. Celá rodina, včetně nejmladších inkarnací s hostitelským rozhraním PCI-e. Kupodivu Advantech dál prodává karty s tímto UARTem a jeho oficiální EOL status sice s úsměvem přiznává, ale dál nijak nekomentuje...

Tím bych ten svůj dinosauří rant mohl pomalu ukončit...