Jaderné noviny – 5. 4. 2012: Závěr přísunu novinek do Linuxu 3.4

23. 4. 2012 | Luboš Doležel | Jaderné noviny | 3626×

Aktuální verze jádra: 3.4-rc1. Citáty týdne: Linus Torvalds, Theo de Raadt, Arnd Bergmann, Paul McKenney. Závěr začleňovacího okna verze 3.4. Linuxový Summit úložišť, souborových systémů a správy paměti 2012: Paměť versus výkon; Vliv jádra.

Obsah

• Aktuální verze jádra: 3.4-rc1
• Citáty týdne: Linus Torvalds, Theo de Raadt, Arnd Bergmann, Paul McKenney
• Závěr začleňovacího okna verze 3.4
• Linuxový Summit úložišť, souborových systémů a správy paměti 2012
  • Paměť versus výkon
  • Vliv jádra

Aktuální verze jádra: 3.4-rc1

Aktuální vývojová verze jádra je 3.4-rc1 vydaná 31. března. Pro přehled změn začleněných do aktuálního vývojového cyklu vizte článek níže.

Stabilní aktualizace: verze 3.0.27, 3.2.14 a 3.3.1 vyšly 2. dubna a obsahují obvyklý dlouhý seznam důležitých oprav.

Citáty týdne: Linus Torvalds, Theo de Raadt, Arnd Bergmann, Paul McKenney

Půlku zábavy na open source programování dělá možnost dělat si veřejně legraci z lidí.

Skutečným důvodem, proč se vyvarovat programování v uzavřeném prostředí je pak právě to, že nemůžete lidi veřejně znemožňovat.

-- Linus Torvalds

 /*
+ * Wikipedia: "Aktuální (13.) b'ak'tun skončí nebo bude dokončen v
+ * 13.0.0.0.0 (21. prosinec 2012 za použití převodu na GMT)".  GMT nebo
+ * Mexico/General? Co je nějakých 6 hodin mezi Mayi.. řiďme se časovou
+ * zónou Mexika.  Možná budete mít 6 hodin na čtení svých e-mailů navíc,
+ * ale nesázejte na to.
+ */
+#define END_13BAKTUN	1356069600
+extern int	emulatemayanprophecy;	/* Ukončit čas dříve než Mayové */

-- Theo de Raadt; Linux je nadále nepřipraven

Možná bych měl říci dalšímu člověku, kdo zašle novou architekturu, aby tuto práci udělal, takhle teď obvykle vývoj v asm-generic funguje.

-- Arnd Bergmann

Ačkoliv si na složitost paralelního programování stěžuje mnoho lidí (zejména v posledních 5-10 letech), pravdou je, že nárůst složitosti paralelního programování oproti sekvenčnímu není takový, jak si obecně lidé myslí. Navzdory tomu, co jste možná slyšeli, ubíjející složitost moderních počítačových systémů není ani tak kvůli přítomností vícero CPU, ale spíše kvůli přítomnosti libovolného CPU. Ve zkratce jde o to, že pro dosažení maximální jednoduchosti počítačového systému je optimální volbou POČET_CPU=0.

-- Paul McKenney

Závěr začleňovacího okna verze 3.4

Začleňovací okno verze 3.4 bylo završeno vydáním Linuxu 3.4-rc1. Ačkoliv se původně mělo za to, že začleňovací okno bude tentokrát poněkud delší, nakonec mělo 13 dnů, a tudíž bylo spíše kratší. Přesto se do něj dostalo mnoho věcí – do hlavní řady bylo zařazeno nějakých 9248 neslučovacích změn. Od předchozích Jaderných novin šlo zejména o toto:

• Cíl „thin provisioning“ v mapovači zařízení [device mapper] nyní podporuje požadavky na rušení [discard], což by mělo umožnit efektivnější používání příslušného úložiště.
• Dále byl začleněn cíl dm-verity. Tento cíl spravuje zařízení, jež je pouze ke čtení, s tím, že všechny bloky jsou ověřovány oproti hashi, který je uložen kdesi jinde. Tímto je dosaženo určité jistoty, že data jsou nedotčená.
• Do jádra bylo začleněno x32 ABI. Na začlenění podpory do kompilátoru a glibc se teprve pracuje a dostat podporu do distribucí potrvá ještě déle, ale základ už bychom měli.
• Byl začleněn framework pro „vysokorychlostní synchronní sériové zařízení“ (HSI). HSI je rozhraním používaným hlavně k propojování procesorů s modemy pro bezdrátové sítě. Bude používáno pro podporu mobilních zařízení v budoucích jádrech.

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

• Společný framework pro správu tiku hodin („common clock framework“) sjednocuje správu hodin v subsystémech, zejména na architektuře ARM (i když není omezen jen na ARM).
• API pro sdílení bufferů DMA bylo rozšířeno tak, aby umožňovalo procesoru přistupovat k bufferům.
• Subsystém pro přímé vykreslování získal počáteční podporu pro sdílení bufferů DMA. Zatím ji žádný ovladač nepoužívá.
• Obrovský soubor asm/system.h byl rozdělen na několik menších.
• Nový soubor /proc/dma-mappings na architektuře ARM zobrazuje aktuálně aktivní koherentní mapování DMA. Vzhledem k tomu, že tato mapování jsou na ARMu nedostatkovým zbožím, jde o užitečný nástroj pro ladění.
• Architektura ARM získala podporu statických návěští [jump label/static branch].
• JIT kompilátor pro filtry paketů BPF byl portován na architekturu ARM.

Linuxový Summit úložišť, souborových systémů a správy paměti 2012

Dvoudenní linuxový Summit úložišť, souborových systémů a správy paměti 2012 se konal dne 1. dubna 2012 v San Fransiscu. Na LWN.net vyšel velmi obsáhlý přehled všech přednášek a diskuzí. Z tohoto přehledu jsme vybrali dvě témata; věříme, že budou pro čtenáře zajímavá.

Paměť versus výkon

Ačkoliv oficiální název tématu, na které Dan Magenheimer hovořil, „Omezování využití paměti při zachování výkonu“, nebylo zvoleno právě jím, přesto jej to neodradilo od toho, aby představil problém, který musejí vývojáři správy paměti brát v úvahu. Nejprve popsal výkonnostní graf při zátěži, kdy se množství dostupné RAM zvyšuje. Přidání RAM snižuje množství času, který zátěž zabere, ale jen do určitého bodu. Dále už přidávání paměti nemá na výkon žádný dopad.

Řekl, že je obtížné nebo dokonce nemožné znát přesné množství RAM potřebné k optimalizaci zátěže. Dva virtuální stroje na jediném fyzickém stroji sdílejí dostupnou paměť, ale jeden VM může potřebovat extra paměť, kterou druhé VM ve skutečnosti nepotřebuje. Je nutné najít vyvážený stav mezi dvěma zátěžemi, které mají podobu těchto dvou VM. Magenheimer hovořil o nápadech, jak o tomto problému uvažovat.

Nejprve situaci přirovnal ke dvěma zemím, jedna z nich potřebuje suroviny, které má ta druhá. Občas to znamená, že spolu půjdou do války, zejména to tak bylo v minulosti, ale v současnosti se při přerozdělování surovin (a dalších zdrojů) spíše hledají ekonomická řešení. Přednášející uvažoval nad tím, zda nejde v jádru použít podobný princip.

Hlavní otázkou je jak rozhodnout, kolik paměti aplikace doopravdy potřebuje versus kolik ji chce. Myšlenkou je najít bod, kdy darování paměti jedné aplikace má na tuto aplikaci zanedbatelný dopad, zatímco druhá aplikace paměť využije ke zvýšení svého výkonu. Kromě sledování velikosti aplikace Magenheimer postuloval, že by bylo možné použít výpočet derivace velikosti růstu, aby se tak získala představa o „rychlosti“ zátěže. Rik van Riel poznamenal, že tuto informaci by bylo složité sledovat, když systému dochází paměť, ale Magenheimer měl za to, že sledování refaultů by s problémem mohlo pomoci.

Magenheimer chce tyto nápady uplatnit v RAMsteru, který umožňuje sdílení nevyužité paměti mezi stroji. RAMster by umožnil strojům vyjednávat uložení stránek jiného stroje. Na systému s osmi stroji by pak například mohlo sedm strojů vnímat zbylý stroj jako paměťový server.

Odhadování velkosti zátěže by mohlo pomoci, ale diskuze se vrátila ke starému nápadu snažit se utahovat šrouby, dokud nedojde ke swapování. To by umožnilo popsat tento problém pomocí řídící teorie [control theory]. Nedílnou součástí této teorie je mít zpětnou vazbu, jenže to je u virtuálních strojů problém.

Glauber Costa upozornil, že část tohoto problému by mohla být zkoumána pomocí paměťových řídících skupin, které se liší velikostí, i když by scházel globální náhled na využití prostředků.

Závěrem přednášky bylo určení problému – jaké prostředky zpětné vazby potřebuje VM, aby bylo možné zhodnotit, kolik paměti zátěž na konkrétním stroji potřebuje?

Vliv jádra

Christoph Lameter započal tím, že prohlásil, že u jeho aplikace (pro rychlé obchodování) každá aktualizace jádra vedla ke zpomalení. To pochopitelně způsobuje značný odpor k aktualizování jádra. Hlavním zdrojem zasahování jádra byly výpadky stránek, meziprocesorová přerušení, jaderná vlákna a démony v uživatelském prostoru. Ti všichni mohou zapříčiňovat latenci, někdy až způsobem, který je pro aplikaci katastrofický. Pokud snaha o zpětné získání [reclaim] paměti způsobí dodatečný drobný výpadek, jde pro jejich aplikaci o velký problém.

Důvod, proč se tak děje, je kvůli určitým trendům. Jádra jsou prostě složitější s vícero zdroji "interference", takže uživateli pak zbývá méně procesorového času. Dalším trendem je pak větší velikost paměti, což vede k delším časům na zpětné získávání, nebo vyšší počet procesorů, takže cykly spouštěné na všech CPU (for-all-cpu) pak trvají déle.

Jedním možným zákrokem proti tomuto by byla izolace aktivit OS na vybranou skupinu CPU, možná pak včetně ošetřování přerušení. Andi Kleen podotkl, že i při izolaci CPU na sebe mohou mít různé procesy vliv, pokud sdílejí stejný soket. Lamenter uznal, že je to pravda, ale i tak by izolace OS měla přínos.

Na některých dále uvedených příkladech (problémech) už lidé pracují, ale zatím to není hotové a nic ještě nebylo začleněno. Faktem je, že s dnešními jádry není situace zrovna optimální. Toto tlačí lidi do situace, kdy jsou vybraná CPU plně izolována a OS je obcházen, co nejvíce to jde, což pak z Linuxu dělá takový lepší zavaděč. Podle něj je v zájmu komunity, aby motivace k takovému chování klesla, čehož lze dosáhnout tím, že se bude hlídat režie způsobená jádrem.

       

Komentáře

[skunkOS]

Tak Theo to zabil. :)

[Ruža Becelin]

Tak Theo to zabil. :)

...a uz to nevstalo. Ani Quick Load nepomohl. Je to uplne mrtvy