Jaderné noviny – 24. 5. 2012: Čtyři bajty, na kterých sejde

11. 6. 2012 | Luboš Doležel | Jaderné noviny | 3935×

Aktuální verze jádra: 3.4. Citáty týdne: Dave Täht, Steven Rostedt, Thomas Gleixner, Linus Torvalds. Otevírá se začleňovací okno verze 3.5. Odstraňování čtyř bajtů z jaderného ABI.

Obsah

• Aktuální verze jádra: 3.4
• Citáty týdne: Dave Täht, Steven Rostedt, Thomas Gleixner, Linus Torvalds
• Otevírá se začleňovací okno verze 3.5
• Odstraňování čtyř bajtů z jaderného ABI

Aktuální verze jádra: 3.4

Vyšlo jádro verze 3.4, a to 20. května. Mezi významné funkce patří bezpečnostní modul Yama, podpora pro x32 ABI, podpora pro asymetrický multiprocessing, dm-verity a ještě více. Další podrobnosti najdete na stránce na KernelNewbies.

Začleňovací okno pro verzi 3.5 je v době psaní článku otevřené, více najdete v článku níže.

Stabilní aktualizace: verze 3.0.32 a 3.3.7 vyšly 21. května, verze 3.2.18 vyšla 21. května a verze 2.6.34.12 vyšla 22. května.

Citáty týdne: Dave Täht, Steven Rostedt, Thomas Gleixner, Linus Torvalds

Dorazil dostatek informací na to, abych byl po všech těch vylepšeních v Linuxu za poslední rok a po BQL, codel a fq_codel spokojen, že jsme zvítězili ve významné bitvě ve válce proti bufferbloatu.

-- Dave Täht

	else if(!strcmp(str, "pony")) {
		tsc_clocksource_reliable = 1;
		sched_clock_stable = 1;
		tsc_perfect_smp_synchronization = 1;
	}

-- Steven Rostedt

	else if (!strcmp(str, "real")
	     panic("Can't handle real TSCs!\n");

-- Thomas Gleixner

Předpověď: místo toho, aby Oracle uznal, že byli s tou svojí dementní žalobou proti Androidu pěkní idioti, tak se budou nakrucovat a budou vykládat, jak jim nakonec bude dáno za pravdu a zaplatí právníkům, aby proces posunuli na vyšší úroveň debility.

Někdy bych si skutečně přál, abych neměl vždycky pravdu. Je to hotové prokletí, to vám povídám.

-- Linus Torvalds

Otevírá se začleňovací okno verze 3.5

Krátce po vydání verze 3.4 Linus rozjel celý proces nanovo s vývojovým cyklem 3.5. Hned první den bylo přetaženo více než 2500 změn a v době psaní tohoto textu jich bylo sloučeno už 4600. Vypadá to, že půjde o zajímavý cyklus se spoustou novinek a odstraněním starého nepořádku. Prozatím zde najdete tyto zajímavé změny viditelné uživatelům:

• Rozhraní pro opravu TCP spojení – užitečné pro implementaci funkčnosti checkpoint/restart.
• Síťový stack získal podporu pro brzkou retransmisi dle RFC 5827, což by mělo urychlit obnovu po ztrátě paketu.
• Algoritmus CoDel pro správu front, který je důležitou součástí řešení problému bufferbloat.
• Mechanismus filtrů seccomp; umožňuje omezit sadu dostupných systémových volání pomocí mechanismu na bázi paketového filtru Berkeley. Více v dokumentaci.
• Bezpečnostní modul Yama má dva restriktivnější režimy pro řízení přístupu k funkčnosti PTRACE_ATTACH.
• Patch pro spolehlivé logování.
• Byl přepsán plánovač NUMA s tím, že bude snad dělat lepší rozhodnutí. Navíc, jak už bylo celé měsíce vyhrožováno, kód plánovače zohledňující správu výkonu byl vyřazen s tím, že někdo jej snad nahradí nečím, co doopravdy funguje.
• V tomto vývojovém cyklu došlo k odstranění spousty kódu včetně ovladače ixp2000, podpory SPARC CPU sun4c, modulu ip_queue (nahrazeno nfnetlink_queue), kompletní podpory Token Ringu, ovladačů pro všechny síťové karty na bázi MCA, podpory pro protokol Econet, podpory procesorů ARMv3 a IXP2xxx (XScale), podpory vývojových desek ST-Ericsson U5500, ovladače sériového portu Motorola 68360 a sledovače pracovních front (workqueue tracer).
• Různé nové ovladače

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

• Spousty variant makra NLA_PUT() používané kolem netlinku byly odstraněny. V kódu by se mělo používat nla_put().
• Vrstva mac80211 má podporu pro synchronizaci MBSS.
• Přibyl nový základ podpory ovladačů pro NFC na bázi specifikace HCI.
• Subsystém „regmap“ má nyní podporu pro registry v I/O paměti.
• Subsystém pro řízení pinů má nyní úplnou podporu pro stromy zařízení.
• Třída androidího „přepínače“ byla zařazena do hlavní řady a rozšířena na obecný framework pro „vnější konektory“.
• Mechanismus „ramoops“ byl přepracován tak, aby používal rozhraní pstore.

Pokud bude platit obvyklý vývojový cyklus, tak můžeme očekávat uzavření okna kolem 4. června. Více se dozvíte v příštích týdnech.

Odstraňování čtyř bajtů z jaderného ABI

Čtyři bajty se nemusejí zdát jako moc místa – a obvykle ani nejsou – ale když je toto místo vyplýtváno milionkrát, tak už se to začíná hromadit. Navíc pokud se tyto bajty staly součástí jaderného ABI (ať už to tak bylo zamýšleno, nebo ne), tak bude těžké se jich zbavit. Tento konkrétní problém byl opět řešen na mailing listu linux-kernel a týká se hlaviček pro sledovací události [trace event].

Je tomu něco přes rok, co jsme se dívali na nevyužité pole lock_depth v hlavičkách událostí. Frederic Weisbecker přidal toto pole jen dočasně, aby pomohlo při odstraňování velkého jaderného zámku (BKL) a jakmile byl BKL fuč, tak Steven Rostedt odstranil tyto čtyři, pak už zbytečné, bajty z hlaviček. Jenže mezitím začal PowerTOP přistupovat k událostem v perf ringu, takže odstranění lock_depth rozbilo PowerTOP. Toto pole nebylo PowerTOPem doopravdy používáno, ale tento nástroj očekával, že struktura bude mít určitou velikost, což se po odstranění zbytečného pole změnilo.

To vedlo k odvolání celého odstranění, což znamená, že každá zaznamenaná událost v ftrace nebo perf má extra režii. Formát událostí je samopopisný, takže není třeba, aby nástroje jako PowerTOP zkoumaly binární data a dělaly předpoklady o formátu těchto dat. Jenže ono bylo snazší číst data napřímo než je parsovat, a proto tak PowerTOP dělal. Rostedt vytvořil knihovnu pro parsování událostí ve formátu, v jakém je jádro poskytuje, aby k podobné situaci v budoucnu už nedošlo. PowerTOP 2.0 tuto knihovnu používá, takže Rostedt poslal prosbu o komentáře, ve které se ptá, kdy by se mělo pole lock_depth odstranit – mezitím bylo přejmenováno na padding.

Linus si nedělal kvůli zbytečným bajtům vrásky, ale chtěl vědět, do kterých distribucí se už dostal nový PowerTOP. Ukázalo se, že PowerTOP ve Fedoře 14 (kterou Linus stále občas používá) je natolik starý, že události perf nepoužívá vůbec. Novější Fedory (16 a 17) používají PowerTOP 1.98, který na jádrech bez padding fungovat nebude.

V diskuzním vlákně byl učiněn předpoklad, že distribuce přejdou na PowerTOP 2.0 ve vydáních, která přijdou ještě letos, ale stále tu máme uživatele, kteří si sestavují vlastní jádra na stávajících distribucích. Existující distribuce mají navíc různé životnosti a některé z nich nepřejdou na nový PowerTOP vůbec. Rostedt se zeptal, jak dlouho jádro musí podporovat starší distribuce. PowerTOP je, jak se ukazuje, v jiné kategorii aplikací, protože jde o vývojářský nástroj. Proto je Torvalds ochoten učinit tuto změnu, i když se tím vykašlou na některé distribuce.

Ale rozbíjení něčeho jako F14-15 nebo něčeho typu SLES (nebo „Debian Starobylní“ nebo jak se říká těm věcem, kde běhají jen prehistorické binárky)? To je v pohodě. Nesmí se to *uchvátat*, ale ne, pokud tyto distribuce v podstatě neaktualizují, tak se o ně nemůžeme navždycky starat kvůli něčemu jako powertop.

U věcí, co rozbíjejí *normální* aplikace, je to jiné. Tam pravidlo musí znít „nikdy“.

Arjan van de Ven souhlasil a ukázal na verzi 3.6, ve které by už se mohl padding odstranit s tím, že ti, kdo neaktualizovali distribuci, aby se k nim tak dostal nový PowerTOP, asi ani nebudou aktualizovat jádro. Rostedt řekl, že patch připraví pro verzi 3.6 nebo 3.7.

Ačkoliv jak Torvaldsovi, tak Ingu Molnarovi přišly čtyři bajty jako nepodstatná věc, Rostedt poukázal na to, že pro uživatele trasování jde o častý problém. Navíc neslouhlasí s Molnarovým tvrzením, že jde jen o kosmetický detail:

4 bajty nejsou kosmetický detail u události, která má 32 bajtů. To je režie 1/8. Kdybychom se mohli zbavit 4 bajtů ze struktury stránky, udělali bychom to? Šlo by jen o 4 bajty na [každých] 4096 bajtů. To je režie jen 1/1024. Události perfu jsou ale samozřejmě větší než 32 bajtů. Je to jedna z největších stížností, které na perf slýchám, totiž stížnosti na velikost jeho událostí. Na zlepšení bychom měli tvrdě pracovat.

V situacích, kde se hraje o každý bajt, například na embedded zařízeních nebo u lidí, co se snaží do svého systému namačkat ještě víc procesů, může snížení režie událostí představovat zlepšení. Zachycení více událostí pomocí stejného objemu paměti zvyšuje šanci na odhalení problému, kvůli kterému bylo trasování povoleno. Když se před rokem problém objevil, David Sharp z Google poznamenal, že velikost událostí představuje pro tohoto vyhledávacího giganta velký problém. A asi nebudou sami.

I když formát dat v ring bufferu perfu může brzo být uzavřenou kapitolou – ačkoliv je možné, že se najdou i další aplikace, co ručně tahají data z tohoto ring bufferu – body sledování [tracepoints] stále představují nedořešený problém v ABI. Zatím se řeší hlavě přidávání bodů sledování, ale jednoho dne bude třeba nějaké odstranit nebo upravit. Pokud budou nástroje záviset na tom, že konkrétní body poskytují konkrétní informace, budou tyto změny představovat problém. A to problém obtížně řešitelný.

       

Komentáře

[pc2005]

podpora pro asymetrický multiprocessing

Můžeš poslat link? Asi jsem slepý, ale v těch odkazech v textu okolo jsem žádnou zmínku nenašel .

[kralyk z abclinuxu]

Asi je to jen spekulace, ale x32 ABI by možná mohlo přinést zrychlení wine záležitostí (čti: her) na x86-64, ne?

[chrono]

Predpokladám, že všetky dôležité časti sú optimalizované a využívajú MMX/SSE, takže pár registrov navyše príliš nepomôže. Navyše "bežná" 32 bitová aplikácia asi nebude fungovať na x32 ABI priamo.

[lyon]

A program compiled to this ABI will run in native 64-bit mode, but with 32-bit pointers and data values. The full register set will be available, as will other advantages of the 64-bit architecture like the faster SYSCALL64 instruction.

Coz podle meho soudu znamena, ze pripadne zrychleni by se tykalo jen wineserveru, ale aplikace jako takova by stejne musela bezet v nativnim 32-bit rezimu. Nejsem si uplne jist, jakym zpusobem by to melo nahradit 32-bit rezim kompatibility (viz odkazovany clanek), kdyz stare 32b binarky s tim stejne fungovat nebudou a nove neni duvod nekompilovat do 64b.

[Luboš Doležel (Doli)]

Cílem je právě nahradit 64bitový režim.

Win32 binárka bude samozřejmě pořád stejná, ale všechen kód Wine by IMO mohl být x32. A to je docela dost.

[lertimir]

Jak jsem už psal před časem v dotazech. Spuštění dvou proudů kopírovaní do pomalejší USB flashky mi v podstatě zastavilo celé KDE asi na 20 minut, než se vše nakopírovalo. Jak jsem pochopil pak z diskuse, problém je v plánovači. Pracuje se na něčem v plánovači, co by bylo schopno udržet prostředí pro uživatele se slušnou reakční dobou i když některé části budou čekat?

[pc2005]

Hmm trochu mě to zní jako problém pro ionice ne?

[Dr. Eddy]

Jaky mas distro?

V Archu s timhle neni problem. Jadro je plne preemptivni, to v Ubuntu myslim nebyvalo. Ale muzes zkusit Brain-fuck scheduler. Ten ale neni v mainline, jen jako patch, jestli se nepletu.

[lertimir]

Distro mám openSUSE, ale podle reakcí jiných na můj dotaz to na distru nezáleží a má to i Arch. A jasně mohu to nějak oflikovat třeba "Brain-fuck" shedulerem, také si mohu dát pozor a s flashkou pracovat tak, že dva proudy tam nedám, ale na druhou strany mě to připadá, že je to systémový problém, a v nějakém delším běhu by se na něm mělo pracovat.

[Michal Kubeček]

Nepomohl ani poslední update jádra (3.1.10-0.9)? Tam by měl být tento problém opraven. Při intenzivnějším zápisu na pomalá zařízení se mi sice nějaké ty záseky pořád objevují, ale ne delší než asi sekundu.

[lertimir]

Nevím. Mám plně aktualizované distro, ale v poslední době jsem takový zápis nezkoušel. Přece jen čas mi byl dražší. Zkusím jak budu mít čas a poreferuji. A i ten případ o kterém jsem referoval byla v podstatě moje chyba ve stylu práce. Standardně jakékoliv větší kopie dělám v krusaderu pomocí jeho funkce "Fronta", pak je zápis dost sekvenční. V tom případě jsem kopíroval dva sety fotek každý tak 3GB a 500 souborů a první jsem poslal do fronty a u druhého jsem se ukliknul a poslal ho přímo kopírovat. Tím vznikly dva paralelní proudy. Celkem si dokážu představit, jak v situaci, kdy tam jely oba proudy současně, se do flasky posílají sektory z každého setu na střídačku a flash se může zbláznit, jak pro každý sektor načte celý erase blok, přepíše jeden sektor a blok zase zapisuje. A je mi jasné, že tímhle jsem snížil rychlost zápisu více než 10 krát (faktická rychlost byly asi 2MB/s). Nicméně v žádném případě, když jeden či několik procesů čeká na HW by to nemělo skoro nijak zasáhnout procesy, které s tím HW nemají, co dělat.

[Kaacz]

oSuse ma z ofiko repos jadro jen 3.1.10. Mám pocit, že vylepšení plánovače pro desktop aby USB IO neblokovalo interaktivni praci prislo ve verzi jadra 3.2. Našel jsem na OBS neofiko repos s jadrem 3.3, ale s tím mi zase nejede Virtualbox ..

[Michal Kubeček]

O dva příspěvky výše píšu, že poslední update na 3.1.10-1.9 ten hlavní problém s THP řeší, je tam i odkaz na bugzillu.

[Kaacz]

No ja si nebyl jisty, jestli "tento problem" (link) je ten problem o kterem je rec. Oficialne to bylo ve vanila 3.2, toz osuse zrejme udelalo backport do 3.1. V tom pripade to asi nefunguje. USB rezie mi tuhne desktop stejne (mozna vice) nez drive.

[Kaacz]

Mno. na druhou stranu .. tento repo-release kernelu 3.1 sice oficialne fixuje odkazovany !! NOVELL !! bug .. jak z toho zjistim, jestli sami neco podrbali nebo jestli backportovali tu upravu z kernelu 3.2 ? Nikdy jsem se v techto vecech nehrabal.

[Kaacz]

Odkazovane CVE nevedly na ten vanila fix. Ale po procteni toho vlakna buzilly to vypada, ze to byla aplikace :toho: patche z 3.2. Mno, tak tam asi jeste zbyva doladit nejakou drobnost. :)

[Kaacz]

Navic nikdy nedelam 2 operace nad jednim usb zarizenim. Ale bezne prehazuju data s tremi USB massstorage najednou. Jako treba kopirovat jeden USB disk na druhy USB disk .. mnamka. :( Ne ze by to vytuhlo tak dlouho. Ale uzasne prace s tim desktopem taky neni.