Jaderné noviny – 20. 8. 2014: Uzavření začleňovacího okna Linuxu 3.17

9. 9. 2014 | Tadeáš Pelech | Jaderné noviny | 3576×

Aktuální verze vývojového jádra: 3.17-rc1. Hrozba poškození dat v úložištích md/raid6. Zmenšování jádra. Začleňovací okno verze 3.17, poslední část.

Obsah

• Aktuální verze vývojového jádra: 3.17-rc1
• Hrozba poškození dat v úložištích md/raid6
• Zmenšování jádra
• Začleňovací okno 3.17, poslední část

Aktuální verze vývojového jádra: 3.17-rc1

Vývojové jádro 3.17-rc1 vyšlo dne 16. srpna (oznámení). Začleňovací okno pokračovalo 3. částí, souhrn všeho, co bylo dosud začleněno, najdete níže.

Stabilní aktualizace: verze 3.16.1, 3.15.10, 3.14.17, 3.10.53 a 3.4.103 vyšly 14. srpna. Aktualizace verze 3.15.10 je poslední pro jádra verze 3.15, jeho uživatelé by měli začít uvažovat o přechodu na jádro verze 3.16.

Hrozba poškození dat v úložištích md/raid6

Neil Brown ze SUSE upozornil 18. srpna na riziko možného poškození dat v úložištích md/raid 6. Jedná se o chybu, která existuje v jádru od verze 2.6.32.

Pokud nastanou následující 3 podmínky:

• dojde k dvojnásobné degradaci pole,
• probíhá obnova jednoho nebo obou poškozených disků,
• probíhá zápis do pole,

hrozí riziko ztráty dat na příslušném poli.

Neil zveřejnil opravu, která tento problém řeší. Pokud se uplatňuje na starší verze jádra, ve kterých jsou ještě oddělené funkce handle_stripe5() a handle_stripe6(), je potřeba změnit druhou ze jmenovaných funkcí.

Tato chyba nemá vliv na pole v optimálním stavu nebo s poškozeným jedním diskem. Stejně tak se netýká pole se dvěma poškozenými disky, u kterých neprobíhá obnova nebo které nedostávají požadavky na zápis.

Zmenšování jádra

Josh Triplett na letošním Kernel Summitu v Chicagu upozornil na trend postupného zvětšování linuxového jádra, které tak přestává být použitelné v malých vestavěných systémech s omezenými možnostmi operační paměti. Zatímco v mobilních telefonech nebo superpočítačích, které disponují dostatkem paměti, to žádný problém nepředstavuje, tvůrci miniaturních počítačů a vestavěných systémů se začínají buď ohlížet do minulosti, nebo poohlížet po jiných operačních systémech určených k práci v reálném čase, což není z pohledu Linuxu nejvhodnější řešení.

Proto Josh vyzývá k trendu zmenšování jádra. Zatímco velké systémy mohou dál využívat bobtnající jádro, které podporuje všechny možné varianty hardwaru, výrobci vestavěných systémů by měli mít možnost vytvořit si verzi aktuálního jádra podstatně – pokud možno až řádově – menší.

Používání jádra verze 2.4 pro miniaturní systémy není podle Joshe vhodným řešením. Toto jádro je opravdu o něco menší, nové vestavěné systémy ale mohou vyžadovat funkce, které jsou k dispozici až v novějších verzích.

Problém současných verzí je ve vzájemné provázanosti jednotlivých subsystémů. Z toho důvodu pak výrobce vestavěného systému nedokáže vynechat funkce, které k ničemu nepotřebuje. Jádro by podle Joshe mělo být sestaveno tak, aby byly jeho jednotlivé subsytémy vzájemně nezávislé.

Náměty k vytváření malých jader jsou shromážděny na tiny.wiki.kernel.org.

Grant Likely namítl, že proti úpravám umožňujícím kompilaci menších jader v principu nic nemá, ale že další volby mohou znepřehlednit už tak složitou soustavu parametrů a možností, které jsou k dispozici v současnosti. Protože požadavků na zmenšování jádra je málo, většina vývojářů se zaměřuje spíš na přidávání nových funkcí, než na optimalizaci stávajících subsytémů a jejich vazeb.

Po diskusi, která se zaměřovala zejména na komplexnost konfiguračních parametrů a možnosti jejich zpřehlednění s ohledem na aktuální hardware, Grant navrhl, že by se několik vývojářů mělo zaměřit na možnosti zmenšování jádra. Uživatel malého systému by měl sestavit seznam systémových volání, která ve vestavěném systému potřebuje, a konfigurační program by měl sestavit takové jádro, které by dané funkce podporovalo. Ale že by se vývojem konfiguračních nástrojů měl zabývat někdo jiný, protože vývojáři jádra mají už tak práce nad hlavu.

Následovala další diskuse o tom, jak si vlastně výrobci vestavěných systémů představují ideální jádro. Vývojáři jádra si nedovedou přesně představit, co všechno by mělo miniaturní jádro zvládat, protože potřeby jednotlivých použití se mohou výrazně lišit.

Na závěr diskuse Josh navrhl, že by se hodila možnost vypnout úplně všechny konfigurační parametry a následně zapnout jen ty položky, které jsou pro dané miniaturní jádro nezbytné. Zda se tento nápad ujme, ukáže až další vývoj. Josh diskusi shrnul konstatováním, že jeho příspěvek přinejmenším upozornil vývojáře jádra na tento problém a může je v budoucnu přimět k vylepšování podpory funkčních miniaturních moderních jader Linuxu.

Začleňovací okno 3.17, poslední část

Linus vydal zkušební verzi 3.17-rc1 a k 16. srpnu uzavřel začleňovací okno pro vydání verze 3.17. Sice navrhl posunout termín uzavření, k této změně ale nakonec nedošlo. Od souhrnu druhé části bylo do hlavní řady zapsáno už jen několik změn. Vybíráme ty nejzajímavější.

• Systém souborů xfs nyní vyžaduje kompilaci jádra se 64bitovými počty sektorů. Pro xfs je také k dispozici adresář v sysfs s několika málo parametry, z nichž většina slouží k testování tohoto systému souborů.
• Klient systému NFS nyní podporuje vyhledávání založené na RCU, což urychluje vyhledávání souborů, pokud jsou příslušné informace uložené v paměti cache.
• Přibyla podpora nového hardwaru, například teplotní řadiče STi, řadičeDMA Allwiner A31, řadiče DMA Renesas Type-AXI NBPF nebo řadiče TI DRA7xx PCIe. U síťových zařízení přibyla podpora ethernetových řadičů APM X-Gene typu SoC.

Nakonec se během začleňovacího okna 3.17 do hlavní řady dostalo 10 890 neslučovacích sad změn. Tento cyklus přešel do fáze stabilizace. Finální verzi 3.17 můžeme očekávat, pokud všechno půjde hladce, někdy začátkem října.

       

Komentáře

[corwin78]

Nějaké informace o implementaci DisplayPort Multi Stream Transport? To je věc, na kterou čekám jak na smilování.

[chrono]

Podpora pre DP 1.2 MST (pravdepodobne len pre niektoré Intel zariadenia) je v Linusovom git repozitári (ktorý je vo verzii 3.17-rc4).

[corwin78]

Dík, doufám, že to brzy dotáhnout, mám na stole laptopy DELL a Lenovo ThinkPad, které na to velmi čekají a port replikátory obou výrobců by myslím měli být podporovány.

[Ragzid]

Jsem sam, komu chybi cerveny text?

[Brumla01]

Nejsi

[melkors]

+1

[Petr Ježek]

A červený hadr nechybí?

[ebik]

Kde nic neni, ani smrd nebere. Co takhle kliknout v ramecku "odkazy a zdroje" na original....

[Petr Ježek]

Vemi podporuji nezávislost všeho toho HW-related harampádí v kernelu. Proč vše tahat do kernelu, když to mohou být na sobě nezávislé a sebou si pouze tahající nezbytnosti moduly? Zdaleka ne pouze malé a RT systémy vyžadují jednoduchost a modularitu, ono i kdejaké kancelářské či domácí PC s dlouhodobě stabilní a nijak předimenzovanou HW konfigurací by se rádo zbavilo zbytečností, jež se týkají pouze v něm nebsažených HW komponent. Ohledně jaderných příkazů je na čase volat pouze to, co je detekováno, nikoli to, co detekováno není.

[R]

Drivery na HW su spravidla kompilovne ako moduly, takze sa vacsina z nich nikdy do pamate nedostane.

[frr]

Souhlas - o drivery nejde, mezi nimi zase tolik vzájemných závislostí není a jdou snadno jednotlivě vyházet.

Nedalo mi to a dohledal jsem si originální podrobný článek na LWN - abych zjistil trochu blíž, o čem se tu vlastně bavíme.

Na tiny.wiki.kernel.org toho mnoho není, ale něco přeci. Je tam vysvětlivka, jak získat nejmenší možný kernel - začít u "make allnoconfig" plus ještě pár ručních úprav. Pak je tam jediná zmínka, že by bylo užitečné nacpat kernel do 256 až 512 kilobajtů ! RAM. Rozbalený!

Ovšem na LWN lze nalézt k tématu samostatný článek - report ze sezení moderovaného Joshem Triplettem na Kernel Summitu. Ten je o něco výživnější - je tam k nalezení pár perliček, které trochu ujasní kontext. Předně je v tom článku graf vývoje "velikosti minimálního kernelu" (rozbaleného v RAM) napříč verzemi jádra od 3.0 výš. Z grafu vyplývá, že rozbalený trojkový kernel v minimální konfiguraci zabírá cca 1 MB RAM. Velikost pomalu roste - jenom v jednom případě mezi verzemi klesla, a to když se podařilo opouzdřit TTY subsystém natolik, že šel v konfiguraci úplně vynechat Další povedená hláška byla, že někdo třeba může cítit potřebu, vynechat z kernelu podporu pro signály (protože je v dané embedded aplikaci nepotřebuje). Nebo že minimální kernel už je bez blokové vrstvy. (!) Byla řeč o platformách, které vydrží fungovat dlouhé měsíce z knoflíkové baterky, pročež nemohou používat DRAM, pouze SRAM.

Osobně považuji za minimální rozumný embedded hardware pro Linux něco s 16-32 MB RAM a aspoň 4 MB flash. Takhle to vychází v OpenWRT, které je docela slušně optimalizované na velikost, při zachování poměrně velké množiny fičur. Na doma skládané distro na bázi glibc, pouze vystripované, na nekomprimovaném FS, na x86, mi kdysi stačilo 16 MB flash, dneska bych dal tak 32-64 MB... ale ony dnešní flashky jsou dávno mnohem větší, takže už při domácím kutění není důvod k askezi.

Já jsem měl z té dnešní debaty původně pocit, že se bude patrně jednat o bobtnání věcí v "kernel core" nebo někde těsně kolem - podpora pro věci, které prostupují jádrem napříč (SMP, schedulery, nějaké fičurky v memory managementu, fronty, zámky, co já vím) - a řekl bych, že jsem nebyl daleko od pravdy. K čemu je někomu kernel bez signálů nebo bez blokové vrstvy? S tím přeci nepůjde použít normální user space, který se skládá ze souborů na nějakém disku... (byť třeba root fs v MTD). A třeba bez TTY nebude možné se na běžící Linux připojit přes telnet ani sériovou konzolu. Zajímavá představa. Fakt je, že už jsem viděl stroje, kde měl user space podobu jediného monolitického bináru. Taky je možné, napsat svoji aplikaci jako modul do kernelu, a pokud by se potlačilo mountování rootfs jakožto završení bootu jádra, mohlo by si jádro vystačit i bez user space...

=> chci říct, že ta dnešní debata o "Tinification" je zjevně o ligu nebo dvě jinde, než obvyklé láteření nad košatícím stromem voleb v menuconfigu. Provozovat Linux na CPU napajeném z knoflíkové baterky, v pár stovkách kB RAM... to mi přijde náměsíčné. Jestli má dnešní minimální kernel 1 MB rozbalený v RAMce, tak mi tahle debata připadá dost akademická.

[Michal Kubeček]

V těchto případech často nejde ani tak o samotné jádro, ale hlavně o velikost datových struktur, které si alokuje. Nedávno jsem třeba zahlédl sadu patchů přidávající ořezanou verzi síťového stacku protože ten standardní je vesměs optimalizovaný na výkon, často i za cenu paměťové neefektivity.

[trekker.dk]

Nedávno jsem třeba zahlédl sadu patchů přidávající ořezanou verzi síťového stacku

IIRC tahle sada souvisela právě s lidmi, co chtějí provozovat kernel na minizařízeních.

[Petr Ježek]

Přesně tohle jsem měl na mysli. Nejde o drivery či jejich moduly či colik dalšího v jádře samotné, ale o data, která se kvůli nim a dalším jaderným prvkům v rámci aplikací a utilit tahají, a to jen proto, že je prostě onen jaderný prvek vyhledán a jeho podpora aktivivána, přičemž zabírá datově kanály i místo.