Jaderné noviny - 19. 5. 2016: Začleňovací okno 4.7 je otevřeno, 1. část

28. 5. 2016 | Redakce

Články - Jaderné noviny - 19. 5. 2016: Začleňovací okno 4.7 je otevřeno, 1. část  

Stav vydání jádra. Citáty týdne: Borislav Petkov, Linus Torvalds. Začleňovací okno 4.7 je otevřeno, 1. část.

Stav vydání jádra

Kernel 4.6 byl vydán 15. května. Linus k tomu řekl: „Nakonec je dobře, že jsem nezkrátil rc cyklus, od minulého týdne se objevilo více oprav, než se čekalo, ale nic nepůsobí divně nebo nepatřičně.“ Nejvýraznější změny v tomto vydání zahrnují: post-init read-only memory jako prvopočátek snah o tvrzení kernelu, podpora ochranných klíčů paměti, systémová volání preadv2() a pwritev2(), jaderný multiplexer připojení, distribuovaný souborový systém OrangeFS, ověření zásobníku při překladu, OOM reaper a mnoho dalšího. Pro úžasný seznam podrobností navštivte stránku vydání 4.6 na webu KernelNewbies.

Začleňovací okno 4.7 je otevřeno, pro podrobnosti o věcech, které již byly začleněny, viz shrnutí níže.

Stabilní aktualizace: Žádné nebyly minulý týden vydány. V době psaní tohoto článku byly aktualizace 4.4.5, 4.4.11 a 3.14.70 v procesu revidování. Nyní by již měly být k dispozici.

Citáty týdne

Po určitém čase stráveném s kernelem je velmi těžké rozeznat hack od promyšleného návrhu.

-Borislav Petkov

Ano já vím, měl jsem tentokrát použít "awk". Žalujte mě. Je to dlouho, co jsem posledně dělal s konečnými automaty v awk. Příkaz "git grep" nemáme namísto "git awk" bezdůvodně.

-Linus Torvalds

Začleňovací okno 4.7, část 1.

Začleňovací okno 4.7 se otevřelo 15. května po vydání jádra verze 4.6. Od té doby Linus začlenil do hlavního repozitáře nejméně 3345 neslučovacích sad změn. Významná část z nich přišla skrze síťový strom, ale došlo na začlenění také dalších stromů (např. virtuální souborový systém se spoustou základních, na první pohled neviditelných, změn). Vypadá to, že se Linus tentokrát rozhodl začít se změnami uvnitř jádra, v době psaní tohoto článku došlo k začlenění také několika stromů ovladačů zařízení.

Mezi nejvýznamnější změny viditelné uživatelům zatím patří následující…

• Došlo k začlenění regulátoru frekvence CPU schedutil. Jedná se o první regulátor, který získává informace o zátěži přímo z plánovače, čímž otevírá novou éru, ve které správa napájení spojená s CPU a plánovač pracují společně. V jádře 4.7 se jedná o poměrně jednoduchou verzi, ale v budoucnu se počítá s vylepšeními. Viz tento seznem změn pro více informací o současném stavu schedutil.
• Systémové volání sigaltstack() nyní podporuje nový příznak SS_AUTODISARM. Dojde-li k označení tohoto příznaku, bude alternativní zásobník signálů zakázán, ale obsluha signálu poběží. To aplikaci umožňuje zavolat swapcontext() bez poškození stavu signálu, což je funkce užitečná hlavně pro dosemu.
• Jádro nyní podporuje „zapouzdřený zavaděč“ EFI, přístupný skrze /dev/efi_capsule_loader. Je užitečný pro nahrávání aktualizací firmwaru v zapouzdřeném formátu EFI, viz tento blogový zápis o jeho užitečnosti.
• Architektura ARM získala podporu pro systémy NUMA (non-uniform memory architecture). Arm64 také nově podporuje hibernaci (uspání na disk).
• Systémová volání preadyv2() a pwritev2() (k jejich začlenění došlo ve vydání 4.6) byla doplněna o nové příznaky, které jsou ale použitelné pouze při operacích zápisu. RWF_SYNC zapisuje data a metadata na perzistentní média po skončení operace, zatímco RWF_DSYNC činí totéž pouze s daty.
• Byla přidána možnost připojovat programy BPF ke sledovacím bodům. Tím se významně zlepšují možnosti dynamického sledování v jádrech hlavní větve.
• Programy BFP použité s moduly pro sledování cls_bpf a act_bpf nyní mohou přistupovat k obsahu packetu přímo – bez nutnosti volat speciální nahrávací funkce. Výsledkem je významný nárůst výkonu, ovšem za cenu možného odhalení dat kernelu uživatelskému prostoru. Tyto programy ale mohou být nahrány pouze privilegovaným uživatelem, takže únik dat by obvykle neměl představovat problém.
• Překladač BPF za chodu (just-in-time) umí provádět „zaslepení konstant“ (constant blinding), tj. zakódování konstantních hodnot v programech BPF, takže je nebude možné využít k nahrávání libovolných instrukcí do jaderného prostoru. Pro více informací viz tento seznam změn.
• Patch od Airbusu přidává podporu protokolu pro bezešvou redundanci s vysokou dostupností (HSR, high-availability seamless redundancy protocol) do síťového subsystému.
• Došlo k přepracování kódu TCP, který je nyní více preemptivní, Mělo by to pomoci vyhlazovat špičky latence při zpracování velkého počtu paketů.
• Kernel nyní podporuje tunelovací protokol GTP-U pro GPRS.
• Nově podporovaný hardware:
  • Systémy a procesory: systémy SGI Ultraviolet UV4
  • Šifrování: Bezpečnostní řadiče Freescale a generátory náhodných čísel HiSilicon
  • Různé: Integrované teploměry Maxim MAX31722/MAX31723 SPI, regulátory výkonu TI LP873X, regulátory napětí Powerventure Semiconductor PV88080, zařízení využívající směrovací protokol Qualcomm IPC, rozhraní NXP PN533 NFC využívající I2C, klávesnice Asus X205TA, GPIO řadiče Loongson 1.

Změny viditelné jaderným vývojářům:

• Semafory čtenářů a písařů je nyní možné zamknout pro zápis pomocí down_write_killable(), což během čekání umožňuje signálem násilně ukončit zamykající proces.
• Došlo ke sloučení prvních částí velkého plánu Thomase Gleixnera k racionalizaci subsystému pro hotplug CPU. Velký konečný automat, který si Thomas představuje, sice ještě není součástí, ale proces přípravy příslušných notifikátorů postupuje kupředu.
• Byl odstraněn kód pro „plovoucí podíly“, popsaný v článku z roku 2007. Všimne si toho jen málo vývojářů. Zjistilo se, že tyto funkce se již nikde v jádře nevyužívají.

• Ve změně, kterou Linus označil za velmi důležitou, může vrstva virtuálního souborového systému provádět více vyhledávání v adresáři současně, čímž se eliminuje významný zdroj konfliktů. Součástí této změny je nová metoda pro strukturu file_operations:

  int (*iterate_shared) (struct file *file, struct dir_context *context);

  Ta funguje jako stávající iterate() až na to, že nyní je možné současně provádět více volání v jednom adresáři. Cílem je odstranit iterate(), jakmile přejdou všecky souborové systémy. V mnoha případech funguje stávající implementace iterate() stejně dobře jako iterate_shared().

Konec dvoutýdenního začleňovacího okna se dá očekávat 29. května. Linus ovšem někdy zavře začleňovací okno dříve. Vzhledem k tomu, že 29. připadá na polovinu svátečního víkendu ve Spojených státech, mohlo by být pokušení zavřít začleňovací okno dříve silnější než obvykle.

Diskuse k tomuto článku

[Joshua]

Načo gtp-u má niekto dáke blizsie informácie? Však to je len vrstva nad udp.. pár bajtov v podstate iba teidy.. či tam je podpora na tunnelovanie cez gtp-u? To by dávalo zmysel ale kto využije?

[JaMa]

http://laforge.gnumonks.org/blog/20160526-gtp-kernel/

[Joshua]

Škoda že linuxove jadro je nepoužiteľné s 10gbit interfaceami.... viac ako 3gbps som ešte nepretlačil cez kernel a s 1500B packetmi... aplikácie napísané pomocou dpdk to dávajú so 64B packetmi :) takže pochybujem že niekto bude čistý linux požívať ako ggsn alebo p-gw... :)

[Jendа]

Kubeček tu snad psal že se 10GE zabývá a zdálo se mi, že vypadal, že mu to funguje. Možná by ti mohl dát nějaké rady.

[Michal]

Testoval jsem 10 Gbps kartu X520-DA2 na E5-2620 @ 2.00GHz a povedlo se mi dosáhnout 4x 9,4 Gbps (2x iperf - v obou směrech na obou portech), tedy celkem blízko k těm 40 Gbps, co karta má. Pomocí pktgen se dařilo vyšplhat až na 11,6 Mpps (60 B). Pozoroval jsem hranici asi 1,6 Mpps na jedno jádro. Limitem byl server, karta ještě mohla.

Na i5-4460 @ 3.20GHz dával iperf 8,5 Gbps jedním směrem, 11 Gbps oběma najednou. Jedno jádro dávalo v pktgen (60 B) okolo 2 Mpps, čtyři pak 7,6 Mpps. Limitem je znovu procesor.

V normálním provozu mám na i5 špičky jen lehce nad 1 Gbps, ale CPU nemá co dělat, takže bych řekl, že vlastnosti provozu odpovídají výsledkům testu.

[ludvik]

On je rozdíl honit to mezi dvěma servery (a ještě iperfem) a nasadit to jako routing pro X desítek tisíc konexí. Zvlášť když člověk musí vypnout MQ, protože s tím se to buď za vteřinu, nebo za šest hodin kousne.

[Michal Kubeček]

Škoda že linuxove jadro je nepoužiteľné s 10gbit interfaceami.... viac ako 3gbps som ešte nepretlačil cez kernel a s 1500B packetmi...

Mně to funguje, našim zákazníkům to funguje, spoustě dalších to funguje… ale asi děláme všichni něco špatně, protože na rozdíl od vás nevíme, že je to nepoužitelné.

[Jiri Kosina]

Škoda že linuxove jadro je nepoužiteľné s 10gbit interfaceami

Existuji (i v cz) ISP, kteri tranzit (radove nasobky 10GE) uspesne routuji linuxovymi routery.

[Marián Kyral]

Příkaz "git grep" nemáme namísto "git awk" bezdůvodně.

V češtině mi to nějak nedává smysl.

Když vezmu originál:

There's a reason there's a "git grep" but not a "git awk" command.

Tak mi vyjde:

To je důvod proč máme "git grep" a nemáme "git awk"

[Václav "Darm" Novák]

To by bylo "That's a reason". Osobně bych to spíš přeložil (trochu volněji) jako:

Není náhodou že máme "git grep", ale ne "git awk".

[Marián Kyral]

Může být

[Fluttershy, yay!]

There's a reason there's a "git grep" but not a "git awk" command.

Tak mi vyjde:

To je důvod proč máme "git grep" a nemáme "git awk"

To ti vyjde špatně.

Slovo od slova by to mělo být „existuje důvod“, odtud dvojitý zápor v článku, který IMHO zní přirozeněji a AFAIK se celkem běžně používá; Darmožroutem navržený překlad je rovněž korektní.

[Václav "Darm" Novák]

Dvojitý zápor v článku není vyloženě špatně, ale hapruje tam zase slovo "namísto".

[Fluttershy, yay!]

IMHO to Linus právě tak myslel, tj. že git podporuje grep na úkor¹ awk.

¹ další slovo, které většina lidí neumí používat

[Václav "Darm" Novák]

Aha, já to z kontextu pochopil právě jako "to že s tím moc neumím je mimo jiné důvod proč najdete třeba git grep a ne git awk"

Vzhledem k tomu že ty nástroje nejsou tak docela jeden náhradou druhého mi to přišlo logičtější.

[Fluttershy, yay!]

Mně přišlo, že awk nepoužívá, protože si vystačí bez něj (tj. třeba s grepem).

[Marián Kyral]

Já to pochopil stejně.

[Marián Kyral]

1. Jsem ani nevěděl, že něco jako git-grep existuje - zatím nikdy jsem jej nepotřeboval
2. Předpokládám, že na githubu (nebo kde se git vyvíjí) už nějaký pull request na git-awk leží. Je to přece opensource a Linux není jediný vývojář

[Václav "Darm" Novák]

Linux není žádný vývojář :D Tedy dokud si kernel neuvědomí sám sebe a nezačne se psát sám :P

[Marián Kyral]

Kurnik. Myslím Linus a napíšu Linux - nějak se nedaří

Marián