![[LTTV]](/images/clanky/bourek/lttv.png)
Portál AbcLinuxu, 5. května 2025 15:33
Aktuální verze jádra: 2.6.34-rc5. Citát týdne: Chris Mason. Ceph: Distribuovaný souborový systém. Oprava governoru ondemand. DM a MD se trochu přibližují. Embedded Linux Conference: Používání LTTng. Když zpětný zápis nefunguje.
Současné vývojové jádro je 2.6.34-rc5 vydané 19. dubna. Různé opravy všude kolem. Nejviditelnější (pro lidi, které to postihlo) bude asi oprava problémů při bootu, které někteří pozorovali (ACPI dělilo nulou: Jaderná bugzilla 15749), ale to je vyřešené. Zkrácený changelog poskytuje dobrý náhled. Zmíněný zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu. Toto vydání má také nové kódové jméno: Sheep on meth (ovce na pervitinu).
Od 1. dubna nevyšly žádné stabilní aktualizace.
-- Chris Mason
Linux Magazine detailně probírá souborový systém Ceph, který byl začleněn do 2.6.34. Pravděpodobně nejdůležitější základní předpoklad při návrhu Cephu je, že jsou úložné systémy velkého rozsahu dynamické a je garantováno, že dojde k selhání. První část tohoto předpokladu – úložné systémy jsou dynamické – znamená, že je hardware přidáván a odebírán a pracovní zátěž se mění. V tomto předpokladu je zahrnuto i to, že bude docházet k výpadkům hardwaru a souborový systém musí být adaptivní a odolný.
napsal Jonathan Corbet, 20. dubna 2010
Subsystém „cpufreq“ je pověřen nastavováním frekvence hodin CPU pro optimální výkon. Definice „optimálního“ se může měnit, takže je k dispozici více governorů – a tím i více politik. Governor „performace“ [výkonnost] nadevšechno priorizuje propustnost, zatímco „powersave“ [úspora energie] se snaží držet spotřebu energie na minimu. Nejčastěji se nicméně používá governor „ondemand“ [dle potřeby], který se snaží držet rovnováhu mezi spotřebou energie a propustností.
Ondemand zjednodušeně funguje takto: Jednou za čas se governor probudí a podívá se, jak vytížené je CPU. Jestliže čas nečinnosti klesne pod určitou mez, frekvence CPU je zvýšena; jestliže naopak doba bez vytížení roste, frekvence se snižuje. Ve výchozím nastavení na systémech s časovači s vysokým rozlišením [high resolution timer] je minimální hodnota doby nečinnosti 5 %; frekvence CPU se sníží, pokud doba nečinnosti překročí 15 %. Minimální procento lze nastavit pomocí sysfs (pod /sys/devices/system/cpu/cpuN/cpufreq/); maximum je zadrátováno na 10 % nad minimem.
Tento governor se nějakou dobu používá, ale jak se ukázalo, v určitých situacích může způsobit potíže. Kdykoliv se zátěž systému rychle střídá mezi fázemi náročnými na výpočetní výkon a na I/O, věci se zpomalí. To proto, že governor vidí nečinný systém a frekvenci procesoru sníží na minimum. Jakmile je CPU opět zaměstnáno, chvíli běží pomalu, dokud governor nezjistí, že se situace změnila. Pak opět dojde na nečinnou fázi a cyklus se opakuje. Jak se stává, taková zátěž je poměrně běžná; „git grep“ a start velkých programů jsou dva příklady.
Arjan van de Ven přišel s opravou, jíž koncept je poměrně jednoduchý. Účtování „času nečinnosti“ se mění tak, že čas trávený čekáním na I/O disku se již nezapočítává – pokud procesor střídá výpočetní fázi s fází čekání na diskové operace, bude procesor považován za nepřetržitě vytížený. Tak zůstane na vyšší frekvenci a bude se chovat lépe. Problém tím mizí, říká Arjan, bez významného zvýšení spotřeby energie.
Ale, jak říká Arjan, na governoru ondemand je toho špatně více a píšu nový, který by opravil mnohem závažnější záležitosti. Tento kód ještě zaslán nebyl, takže není jasné, jaké heuristiky bude obsahovat. Zůstaňte na příjmu; governor „dle potřeby“ už brzy možná nebude zapotřebí.
napsal Jonathan Corbet, 20. dubna 2010
Správa RAID polí v jádře je komplikovaný úkol – a závisí na něm osud mnoha dat. Vzhledem k tomu by dávalo smysl mít jedinou sadu funkcí pro RAID, kterou by vylepšovali všichni. Linuxové jádro má místo toho tři samostatné implementace RAIDu: v subsystému násobného zařízení [MD, multiple device], v device mapperu (DM) a v souborovém systému Btrfs. Často bylo řečeno, že by bylo dobré tyto implementace sjednotit, ale to není jednoduché a zatím se tak ještě nestalo.
Správce MD Neil Brown nyní udělal krok tímto směrem a zaslal modul dm-raid456, implementaci RAIDu pro device mapper založenou na kódu MD. Tato sada patchů má potenciál odstranit velký kus duplicitního kódu, což může být jenom dobře. Také přináší do vrstvy device mapperu některé hezké vlastnosti, mezi nimi podporu RAID6, násobných cílů [multiple-target] a další.
Jedná se o práci v počátečním stádiu vývoje, která pravděpodobně nemíří do příštího začleňovacího okna. Odezva ze strany device mapperu byla ale vcelku kladná. Se štěstím tedy jednoho dne budou oba subsystémy pro RAID používat stejný kód.
napsal Jake Edge, 21. dubna 2010
Na letošní Embedded Linux Conference bylo k vidění několik prezentací o sledování [tracing], včetně praktického návodu k Sadě sledovacích nástrojů pro Linux nové generace (Linux Trace Toolkit next generation, LTTng), který přednesl Mathieu Desnoyers. Mathieu převedl, jak pomocí LTTng vyřešit reálné problémy s výkonností a latencemi, přičemž poskytl dobrou ukázku toho, jak se v linuxovém jádře řeší problémy. Přednáška byla zaměřena na vývojáře embedded zařízení, ale prezentace je užitečná pro kohokoliv, kdo chce najít a řešit problémy v Linuxu nebo v aplikacích, které pod ním běží.
Mathieu na jádře pracuje mnoho let a nedávno získal titul Ph.D. v oboru computer engineering hlavně za svou práci na LTTng. Od té doby má vlastní firmu, EfficiOS, která nabízí konzultace k LTTng a také pomáhá různým zákazníkům diagnostikovat problémy s výkonností. Kromě samotného LTTng také vyvinul RCU knihovnu v uživatelském prostoru, která umožňuje procesům v uživatelském prostoru používat synchronizační techniku čtení-kopírování-aktualizace [read-copy-update, RCU], kterou používá jádro.
LTTng se skládá ze tří samostatných komponent: Z patchů pro linuxové jádro, které přidávají sledovací body, infrastrukturu LTTng a kruhový buffer, dále je zde řídící aplikace LTT v uživatelském prostoru a GUI rozhraní LTTV pro zobrazení výstupu. Všechno je k dispozici na webové stránce LTTng a verze jsou dostupné pro jádra od 2.6.12 dále. Také je k dispozici rozsáhlá dokumentace.
Bezzámkové hodiny pro sledování jsou významný kus LTTng, který závisí na architektuře. Tyto hodiny představují vysoce přesnou časovou značku odvozenou od čítače cyklů v procesoru, která se připojuje ke každé sledované události. Časová značka je koordinována mezi procesory, což umožňuje seřadit události celosystémově. Na procesorech se škálováním frekvence a nesynchronizovanými čítači, jako jsou některé x86 systémy, mohou být sledovací hodiny zmateny, když se změní taktovací frekvence procesoru, takže tuto funkci je nutné před sledováním vypnout. Mathieu podotkl, že Nokia sponzorovala práci na tom, aby se LTTng umělo správně vyrovnat se změnami frekvencí a vlastnostmi pro správu napájení u ARM procesoru OMAP3, ale u x86 to ještě zvládnuto nebylo.
Část přednášky se zabývala výhodami a nevýhodami jednotlivých strategií sledování. Mathieu popsal faktory, které je nutné zvažovat, když se člověk rozhoduje o tom, jak sledovat určitý problém; mezi ně patří, o jaký druh chyby se jedná, jak dobře lze reprodukovat, jak velkou režii sledování bude systém tolerovat, dostupnost systémů, na kterých se bude reprodukovat, jestli se objevuje pouze na produkčních systémech a tak dál. Každá z těchto věcí má dopad na počet iterací, které jsou k dispozici. Když se chyba nevyskytuje často nebo je na produkčním systému třetí strany, může být k dispozici výsledek pouze jediného běhu sledování; nebo máte k dispozici luxus opakovaných sledování.
V závislosti na těchto faktorech si lze vybrat z několika možností sledování pomocí LTTng. Na nejvyšší úrovni můžete použít sledování výrobce – spotřebitel [producer – consumer], kde se všechny zaznamenané události uloží na souborový systém. Také je k dispozici režim „černá skříňka“ [flight recorder], kde se události ukládají do paměťových bufferů pevné velikosti a novější události přepisují staré, popřípadě mohou oba tyto režimy běžet naráz. Obě možnosti mají samozřejmě své výhody a nevýhody, režim výrobce – spotřebitel má velkou režii, ale na druhou stranu může většinou uložit víc dat než sledování černou skříňkou.
Protože je výsledkem sledování obvykle ohromné množství dat, Mathieu popsal několik technik, které mohou zaostřit na problémovou oblast. V LTTng jsou události seskupeny podle subsystémů do „kanálů“ a každý kanál může mít jinou velikost bufferu pro režim černé skříňky – tak může být pro některé události zaznamenána delší historie a pro jiné kratší. Navíc je možné osazení (sledovací události [trace events], jaderné značky [kernel marker]) zakázat, aby se omezilo množství sledovaných dat, která jsou generována.
Další technikou je používání „kotev“ [anchor], což jsou specifické události, které označují počáteční bod analýzy. Kotva se často používá tak, že se od ní jde ve sledování zpět. Může pocházet buď z osazení [instrumentation], jako jsou sledovač uživatelského prostoru LTTng či jaderné události sledování, nebo je může generovat analýza sama o sobě. Největší rozptyl [jitter] přerušení časovače (tj. jak je tato událost časově vzdálena od času, kdy k ní mělo dojít) je jedním příkladem kotvy generované analýzou.
Mathieu demonstroval LTTng na dvou problémech, které oba zahrnovaly plánovač. První ukázka zahrnovala pokus identifikovat zdroje zpoždění audia spuštěním programu s periodickým časovačem, který vypršel každých 10 ms. Kód byl napsán tak, aby vložil kotvu do výstupu sledování pokaždé, kdy časovač minul o více než 5ms. Mathieu program spustil a pak hýbal oknem na obrazovce, což způsobilo zpoždění časovače až 60 ms.
Pak tato data použil a pomocí LTTV GUI se díval na to, co se děje. Bylo poněkud obtížné sledovat, co přesně dělal, ale nakonec problém zúžil na plánování X serveru. Poté osadil jaderný plánovač jadernou značkou, aby získal víc informací o tom, jak se rozhoduje. Jaderné značky byly již dávno navrženy k začlenění do hlavní řady, ale byly kritizovány za to, že přecpávají jádro věcmi, které vypadají jako ladící printk(). Značky jsou dobré jako sledovací body ad hoc, ale do upstreamu se je začlenit nepokoušejte, varoval.
Další demo se dívalo na podtečení zásobníku v utilitě aplay z ALSA. Ke zkoumání problému byla využita stejná značka.
Pravděpodobně nejobtížnější otázka zbyla na konec prezentace: Jaký je stav ohledně začlenění LTTng do hlavní řady? Mathieu je v tomto ohledu optimista, částečně protože v oblasti sledování jádra došlo k velkým pokrokům. Většina osazení je již začleněna a na sledovači samotném se pracuje, když na to teď je čas. Prezentaci „stav LTTng“ měl Mathieu na Linux Foundation Collaboration Summit (LFCS), který se konal těsně po ELC, a mezi vývojáři sledování panovala shoda, že by bylo vhodné spolupracovat na tom, aby se do jádra dostalo víc z LTTng.
Mathieu nevidí problém v tom mít v jádru několik sledovačů, pokud budou používat společnou infrastrukturu a cílit na jiné případy použití. Ftrace se orientuje více na vývojáře jádra, řekl, má různé sledovače pro různé účely. LTTng na druhou stranu míří na uživatele a na programátory v uživatelském prostoru, kteří se kvůli diagnostikování svých problémů potřebují podívat do jádra. Vývojář Ftrace Steven Rostedt se účastnil přednášek jak na ELC, tak na LFCS a s mnoha Mathieuovými nápady souhlasil; jsou tedy dobré vyhlídky na to, že přinejmenším některé části LTTng se během následujícího roku dostanou do hlavní řady.
napsal Jonathan Corbet, 20. dubna 2010
Jako jakékoliv jádro, které se stará o výkonnost, ani Linux nezapisuje data zapsaná do souboru okamžitě na disk. Cachování dat v paměti může pomoci optimalizovat rozvržení souborového systému a doby přesunu hlaviček; také odstraňuje duplikované zápisy do stejných bloků, když se do nich zapíše rychle po sobě. Dříve či později (lépe dříve) ale musí data dorazit na trvalé úložiště; proces, který je tam dostane, se nazývá „zpětný zápis“ [writeback]. Jak ale některé nedávné diskuze bohužel ukazují, kód zpětného zápisu v Linuxu není aktuálně úplně v pořádku.
V současných jádrech se zpětný zápis provádí dvěma způsoby. Sada jaderných vláken řeší zpětný zápis na specifické blokové zařízení a snaží se každé zařízení co nejvíce zaměstnávat. Zpětný zápis ale také probíhá ve formě „přímého znovuzískávání“ [direct reclaim], přičemž se zdá, že tam spočívají problémy. K přímému znovuzískávání dochází, když hlavnímu alokátoru paměti dochází paměť; než aby alokace selhala, subsystém správy paměti se rozhlédne kolem sebe a hledá stránky, které by mohl uvolnit. Jakmile je uvolněno dost paměti, alokátor se znovu podívá a doufá, že mu někdo stránky, kvůli kterým se musel tak namáhat, nevyfoukl.
David Chinner nedávno narazil na problém, který se týká přímého znovuzískávání a který způsobuje přetečení jaderného zásobníku. Znovuzískávání může být spuštěno v důsledku téměř jakéhokoliv volání pro alokaci paměti, což znamená, že se může přilepit na konec téměř libovolného řetězu volání funkcí [call chain]. Když je tedy znovuzískávání spuštěno, velká část jaderného zásobníku může být obsazena. Jaderné zásobníky jsou malé – obvykle ne větší než 8 kB a často mají pouze 4 kB – takže v nich ani za nejlepších okolností není moc místa nazbyt.
Problém je v tom, že znovuzískávání může samo o sobě používat velmi složité kódové cesty. Získání nečistých stránek přinejlepším zahrnuje volání kódu souborového systému, který je sám o sobě komplexní. Jestliže je ale tento souborový systém součástí sjednoceného připojení [union mount], které sedí nad RAID zařízením, které je vytvořeno z iSCSI disků distribuovaných po síti, výsledný řetěz volání může být opravdu hluboký. Rozhodně to není úloha, kterou by někdo chtěl zkoušet v situaci, kdy je místo na zásobníku již vyčerpáno.
Dave narazil na přetečení zásobníku – s 8k zásobníkem – když pracoval s XFS. XFS není známý tím, že by k zásobníku přistupoval minimalisticky, ale na tom sotva záleží; v případě, který Dave popisuje, bylo na zásobníku zabráno 3 k místa ještě předtím, než se XFS dostal ke slovu. Zjevně se jedná o situaci, kdy se věci mohou snadno pokazit – Davovou odpovědí je patch, který v kódu přímého znovuzískávání zakazuje používání zpětného zápisu. Místo toho se znovuzískávání musí spokojit s nakopnutím zapisovacích vláken [flusher threads] a použitím čistých stránek, které najde.
Vyhýbání se zpětnému zápisu má při přímém znovuzískávání ještě jednu výhodu: Zapisovací vlákna mohou nashromáždit sousedící bloky na disku a pokusit se zapsat data tak, aby se co nejméně pohybovalo s hlavičkami disku a tím se maximalizovala propustnost. Znovuzískávání místo toho bere stránky ze seznamu nejdéle nepoužívaných [least-recently-used, LRU] s cílem uvolnit stránky ve specifické oblasti. Výsledkem je, že jsou následně zapisovány rozptýlené stránky, což způsobuje víc pohybů hlavičkami a horší výkonnost. Zakázání zpětného zápisu tedy vypadá jako vítězná strategie.
Samozřejmě až na to, že tady mluvíme o kódu správy virtuální paměti a tam není nic jednoduché. Jak upozornil Mel Gorman, nečekání na zpětný zápis může snadno způsobit, že znovuzískávání častěji selže. To může následně systém vrhnout do stavu vyčerpané paměti, což jenom zřídka bývá příjemná zkušenost pro toho, kdo ji zažije. A nejedná se o pouhou teoretickou obavu; v Googlu i jinde bylo takové chování pozorováno.
Při přímém znovuzískávání také probíhá uvolňování po kusech [lumpy reclaim]. Algoritmus uvolňování po kusech se pokouší uvolňovat stránky ve fyzicky spojitých (v RAM) kusech, čímž minimalizuje fragmentaci paměti a zvyšuje spolehlivost alokací vyšších řádů. Zde je však nutné měnit něco za něco: Povaha virtuální paměti je taková, že jsou stránky ve fyzicky spojitém bloku paměti široce rozptýleny na úložném zařízení. Uvolňování po kusech má tedy v povaze vytváření I/O práce s častým přesunem hlaviček, ale když se vynechá, zvyšuje se pravděpodobnost selhání alokací vyšších řádů.
Zvažována tedy byla různá další řešení. Jedno z nich bylo jádru nařídit novou dietu, co se využívání zásobníku týče, s tím, že se snad v budoucnu podaří zabránit přetečení zásobníku. Výpis Davova zásobníku například ukazuje, že systémové volání select() zabere 1600 bytů zásobníku předtím, než vůbec začne něco dělat. Opět ale jde o chování něco za něco: select() se tak chová, aby omezil alokace (a vylepšil výkonnost) v běžném případě, kdy je počet popisovačů souborů relativně malý. Omezení využívání zásobníku by toto systémové volání – často kritické pro výkonnost – zpomalilo.
A kromě toho je omezení využívání zásobníku – i když je to užitečné samo o sobě – považováno přinejlepším za dočasnou opravu. Taková oprava může zajistit, že specifický řetěz volání bude fungovat, ale dokud bude možné spouštět libovolně složité kódové cesty zpětného zápisu s libovolně velkým zabraným místem na zásobníku, někdy se objeví problémy. Je tedy potřeba trvalejší oprava; zásobníková dieta může poskytnout nějaký čas, ale problém skutečně nevyřeší.
Jeden častěji se vyskytující návrh bylo přesunout přímé znovuzískávání do samostatného jaderného vlákna. To by ho (a zpětný zápis) přesunulo do vlastního zásobníku, kde by se nesoupeřilo s jinými systémovými voláními a dalším jaderným kódem. Když by bylo potřeba uvolnit paměť, kód alokace paměti by do tohoto vlákna mohl šťouchnout a případně blokovat, dokud se nějaké stránky neuvolní. Také by mohlo být možné vylepšit kód uvolňování po kusech, aby nezpůsoboval tolik hýbání hlavičkami.
Další možnost je prostě zvětšit jaderný zásobník. Nicméně vzhledem k tomu, že jsou pozorována přetečení při 8 k, bylo by zapotřebí rozšíření na 16 k. Tento nárůst využívání paměti by nebyl vítán a větší alokace vyžadované kvůli těmto zásobníkům by zvýšily tlak na kód uvolňování po kusech. Toto rozšíření ale i tak může být jednou na pořadu dne.
Podle Andrewa Mortona však problém spočívá jinde:
Jinými slovy problém nespočívá v tom, jak se chová přímé znovuzískávání, ale že k němu dochází tak často. Kdyby nebylo zapotřebí znovuzískávat tak často, problémy, které způsobuje, by nebyly tak palčivé.
Jestliže se tedy dá na Andrewa, tato práce se zaměří na to, proč se změnilo chování kódu správy paměti a jak to opravit. Za tímto účelem Dave zaslal sadu sledovacích bodů, které by měly trochu zviditelnit to, jak se kód zpětného zápisu rozhoduje. Tyto sledovací body již odhalily několik chyb, které byly opraveny. Hlavní problém nicméně zůstává neopraven. Již nyní byl tedy naplánován jako jedno téma k diskuzi pro nadcházející workshop zabývající se souborovými systémy, úložišti a správou paměti (odehraje se v srpnu na LinuxCon), ale mnoho ze zainteresovaných lidí doufá, že do té doby již bude známo řešení.
, mě téměř nepřetržitě stačí 800MHz takt CPU - výjimka je jenom přehrávání HD videa (obzvlášť na youtube)
Ta změna frekvence není žádná megaoperace, vyplatí se to už i kvůli kratičkým zátěžím.Dokumentace jádra říká:
If you have a desktop machine then you should really be considering the 'ondemand' governor instead, however if you are using a laptop, PDA or even an AMD64 based computer (due to the unacceptable step-by-step latency issues between the minimum and maximum frequency transitions in the CPU) you will probably want to use this governor.K tvému
Obecně nechápu v čem by byl správce podobný ondemand, jenom reagující mnohem pomaleji, lepší. Nebo i jen dobrý.Například kvůli úspoře energie (dokud 800MHz procesor stíhá dost rychle na to, abych na něj nečekal, nemám důvod chtít víc) či nižším otáčkám větráku (mě zbytečnej kravál vadí i ve dne) A když už opravdu potřebuju výkon, který ten procesor má, většinou je to záležitost na několik minut či hodin. V takovém případě mě pár vteřin, než se procesor přepne do nejrychlejšího režimu, opravdu netrápí
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
5.5.2010 15:10
5.5.2010 14:36