Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

28. 11. 2011 | Luboš Doležel

Články - Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O  

Aktuální verze jádra: 3.2-rc2. Citáty týdne: Andrew Morton, Matthew Garrett. Velké stránky, pomalé disky a velké prodlevy.

Obsah

• Aktuální verze jádra: 3.2-rc2
• Citáty týdne: Andrew Morton, Matthew Garrett
• Velké stránky, pomalé disky a velké prodlevy

Aktuální verze jádra: 3.2-rc2

Aktuální vývojová verze jádra je 3.2-rc2 vydaná 15. listopadu. A na to, že je to -rc2 vydání po dost velkém začleňovacím okně, to má docela rozumnou velikost. Faktem je, že ačkoliv toto byl největší linux-next ve vydání za celou historii linux-next (myslím), rc2 má úplně stejné množství commitů, jako jsme měli během vydání 3.1. Obsahuje mnoho oprav a pár vylepšení v ktest.

Stabilní aktualizace: stabilní jádra 3.0.9 a 3.1.1 vyšla 11. listopadu. Obě obsahují velmi dlouhou řadu důležitých oprav.

Citáty týdne: Andrew Morton, Matthew Garrett

A co v rámci memcg znamená pgfault/pgmajfault? Mám strach se zeptat – vzhledem k situaci s pgpgin/pgpgout mají tyto pravděpodobně souvislost s viskozitou mého šamponu nebo tak něco.

-- Andrew Morton

Je těžké s jistotou vědět, co je správně – k interakci mezi těmito všemi komponenty neexistuje žádná veřejně dostupná dokumentace. Ale dostatečné množství výrobců povoluje ASPM na platformách a pak nastaví tento bit, takže je pravděpodobné, že očekávají od OS, že do toho nebude sahat.

Podle měření to uspoří kolem 5 W na nečinném Thinkpadu X220.

-- Matthew Garrett možná opravuje závažný problém se spotřebou

Velké stránky, pomalé disky a velké prodlevy

Není to časté, ale není to sranda, když se to přihodí. Zapojte pomalé úložiště – například USB disk nebo hudební přehrávač – a spusťte něco jako rsync pro přesun velkého množství dat na tento disk. Tato operace chvíli potrvá, což nepřekvapí, ale více překvapí to, když se náhodné procesy začnou zasekávat. V nejhorších případech se desktop může zaseknout na celé minuty; netřeba říkat, že tohle není ten typ odezvy, co by si uživatelé přáli. Problém se může objevit na zdánlivě náhodných místech; zasekne se webový prohlížeč, ale síťový stream se zvukem se přehrává bez zaseknutí. Nakonec se všechno odblokuje, ale tou dobou už si uživatel dává třetí pivo a rozmýšlí o přednostech proprietárních systémů. Není hanbou si pak myslet, že by systém měl fungovat o něco lépe.

Tento typ chování hlásí v poslední době mnoho lidí; váš redaktor to také zaznamenal. Ale je obtížné to zreprodukovat, což znamená, že je těžké to vysledovat. Je taky docela dobře možné, že toto chování způsobuje více než jedna chyba. Tak či tak by mělo být o jednu takovou chybu méně, pokud patch od Mela Gormana bude fungovat. Několik vývojářů nicméně přemýšlí, jestli není lék v některých případech horší než samotná choroba.

Problém, který Mel našel, se chová asi takhle. Proces (třeba ten webový prohlížeč) dělá svou práci a najednou vyvolá výpadek stránky. To je normální; někdy se zdá, že jediným smyslem současných prohlížečů je „stress test“ systémů pro správu virtuální paměti. Jádro na to odpoví tím, že vezme volnou stránku pro adresní prostor procesu. Ale pokud je do jádra vestavěna podpora transparentních velkých stránek (a většina distributorů tuto funkci povoluje), ošetřování výpadků stránek se pokusí alokovat velkou stránku. S trochou štěstí bude zrovna na tuto příležitost čekat jedna velká stránka, ale ne vždycky tomu tak je; zejména, pokud je tu proces, který znečišťuje spoustu paměti, nemusí žádné velké stránky zbývat. V ten moment to začne jít z kopce.

Je nutné předpokládat, že jednou za čas, kdy systém už nějakou dobu běží, velké souvislé kusy paměti přestanou být k mání. Správa virtuální paměti má tendenci takové kusy rychle fragmentovat. Takže není dobré předpokládat, že velké stránky budou někde jen tak vysedávat; jádro se musí extra přičinit o to, aby takové stránky vznikly. Říká se tomu kompakce [compaction]: přesouvání stránek tak, aby se volné místo defragmentovalo a opět se zrodily velké stránky. Bez kompakce by funkce jako velké transparentní stránky byly neúčinné.

Mnoho kompakce se provádí na pozadí. Ale současná jádra dělají i „synchronní kompakci“, pokud by alokace velké stránky měla selhat kvůli nedostupnosti. Proces, který se o takovou alokaci snaží, skončí u migrování stránek ve snaze o vytvoření velké stránky, o kterou žádá. Tato operace v nejlepším případě není jen tak zadarmo, ale nemělo by docházet k několikasekundovým (nebo minutovým) prodlevám. Zde přichází na řadu USB disk.

Pokud se mnoho dat zapisuje na pomalé úložiště, paměť bude rychle zaplněna špinavými stránkami čekajícími na zápis. To samo o sobě může být problém, proto se nedávno začleněný kód pro brzdění takových operací hodně snaží, aby stránky pro jediné zařízení nezabraly příliš mnoho paměti. Ale zpětný zápis na pomalé zařízení nefunguje s kompakcí moc dobře; kód pro správu paměti nemůže migrovat stránku určenou pro zápis, dokud se I/O nedokončí. Když synchronní kompakce narazí na takovou stránku, bude čekat na dokončení I/O. Pokud stránka míří na pomalé zařízení a je v zadní části fronty plné spousty takových stránek, čekání může trvat dlouho.

Nesmíme zapomenout, že vytvoření jedné velké stránky může znamenat migraci stovek obyčejných stránek. Takže jakmile skončí čekání, práce není ještě zdaleka hotová; proces provádějící kompakci se může do dokončení práce dostat na konec fronty pro zápis ještě několikrát, než bude konečně výpadek stránky vyřešen. Jedině tehdy bude moci v práci pokračovat kód, který chtěl uživatel spustit – než dojde k dalšímu výpadku stránky a celé šílenství začne nanovo.

Melova oprava je jednořádková: pokud se proces snaží alokovat velkou transparentní stránku, synchronní kompakce nebude provedena. Mel došel k závěru, že v této situaci je lepší dát procesu obyčejnou stránku a nechat jej běžet dál. Zajímavé je to, že ne všichni s ním souhlasí.

Andrew Morton měl námitky jako první, řka: „Někteří lidé asi dají přednost tomu, aby pro svou výpočetní úlohu o 1000 hodinách dostali spousty velkých stránek a trocha čekání na tyto stránky je přijatelná.“ David Rientjes, pravděpodobně mysleje na úlohy v Google orientované na propustnost, řekl, že někdy je latence naprosto přijatelná a někdy úlohy při výpadku stránky opravdu chtějí dostat velké stránky. Melova změna způsobuje to, že je méně pravděpodobné, že při výpadku budou velké stránky alokovány; David to zjevně nevnímá jako dobrou věc.

Někdo by mohl odpovědět (a Mel odpověděl), že mechanismus transparentních velkých stránek nefunguje jen při výpadku stránky. Jádro se bude snažit nahradit malé stránky na pozadí, zatímco proces běží; tento mechanismus by mohl přinést více velkých stránek – alespoň pro déle běžící procesy – i když nejsou v době výpadku dostupné. V případech, kdy to nestačí, se mluvilo o přidání nového čudlíku, který by umožnil administrátorovi nastavit, že se má používat synchronní kompakce. Sémantika takového čudlíku není jasná; dalo by se argumentovat, že když jsou alokace velkých stránek tak moc důležitější než latence, systém by měl také agresivněji získávat zpět stránky.

Andrea Arcangeli to okomentoval slovy, že se mu nelíbí, jakým způsobem Melova změna vede k nepoužívání velkých stránek při výpadcích; podle něj by bylo lepší najít způsob, jak zabránit synchronní kompakci v tom, aby zůstávala viset. Objevilo se několik nápadů, jak to udělat, ale v době psaní tohoto textu nebylo nalezeno žádné řešení.

Tyto drobnosti půjde jistě časem vyřešit. Pokud se mezitím ukáže, že je Melův patch nejlepším řešením, rozhodnutí jej začlenit by mělo být jisté. Když jde o to vybrat si mezi 1) systémem, který reaguje i během intenzivního I/O u pomalých zařízení a 2) náhodnými, dlouhými záseky v těchto situacích, můžeme hádat, že většina uživatelů si vybere to první. Pokud se nevyskytnou komplikace, můžeme tento patch očekávat v hlavní řadě docela brzo a ve stabilním stromě snad nedlouho poté.

Diskuse k tomuto článku

[test test]

Pekny clanok, na ktory sa kazdy pondelok tesim...

Ale k veci. Skusal niekto spocitat, kolko synchronnych alokacii sa na beznom desktope vykona v priemere behom hodiny prace a aky je ich histogram trvania? Je to nejako jednoducho odmeratelne na mojom aktualnom systeme? Ak hej, poprosim jednoduchy navod a poskytnem zan vysledky merania

[Michal Kubeček]

Několik vývojářů nicméně přemýšlí, jestli není lék v některých případech lepší než samotná choroba.

Nemělo tam být "horší"?

[Luboš Doležel (Doli)]

Jasně, pardon.

[salam]

Mně se nezdá ani to přemýšlí, co třeba Několik vývojářů si nicméně myslí?

[Luboš Doležel (Doli)]

V originále je are wondering, nikoliv think.

[belisarivs]

Hm.

Jirka Bourek uz nepreklada?

At jaderne novinky preklada kdokoliv, odvadi sakra dobrou praci.

[Luboš Doležel (Doli)]

Jirka už je nepřekládá, proto jsem to po něm převzal já. Takže děkuju

[salam]

a co třeba se zamýšlejí nad tím, zda není lék v některých případech horší než samotná choroba?

[Luboš Doležel (Doli)]

Není to to samé?

[gm]

muze mi nekdo prosim vysvetlit co je to velka stranka? stranka (page) na 4kB, takze velkou strankou se mysli vetsi mnozstvi stranek, tj. nejaky souvisly blok? nejaky terminus technicus nebo anglicky ekvivalent by nebyl?

[gm]

tak jsem zkusil dostudovat, hmm zajimave ... vzdy jsem mel pocit, ze strankovani tu je kvuli fragmentaci ...

[Luk]

muze mi nekdo prosim vysvetlit co je to velka stranka? stranka (page) na 4kB, takze velkou strankou se mysli vetsi mnozstvi stranek, tj. nejaky souvisly blok?

To jsou prostě velké stránky. Konkrétní velikosti závisí na architektuře. V dobách systémů s paměti v řádu MB byly stránky velké 4 KB tak akorát, u pamětí v GB už je to příliš malá velikost, která generuje spoustu zbytečné režie. Proto se používají i velké stránky.

nejaky terminus technicus nebo anglicky ekvivalent by nebyl?

Huge page

[Mandarinka]

U x264 by se prý dala eliminovat většina TLB missů a zvednout tak o něco výkon (počítám, že by se to hlavně dotklo systémů bez HT), pokud by se daly používat velké stránky. Vývojáři ale mají potíže s tím, že na velké stránky je potřeba roota a transaprentní stránky jim asi pořádně nejdou... takže prý by potřebovali vlastní malloc či co, uvidí se...

[kralyk z abclinuxu]

Vývojáři ale mají potíže s tím, že na velké stránky je potřeba roota

Jo, tohle je problém. Úplně stejná situace nastává, když chce člověk při použítí nějaký kryptografie zamknout kus paměti (typicky klíč) v RAM proti odswapování (mlock()), na to je taky potřeba root, takže v praxi to je v podstatě nepoužitelný :-/

Chtělo by to mít možnost tyhle věci nastavit per-process i pro neprivilegovaný procesy, s nějakými omezeními samozřejmě...

[michich]

Na mlock() nemusíš být root, ale musíš se vejít do limitu (ulimit -l, memlock v limits.conf).

[kralyk z abclinuxu]

Aha, díky, tak fajn, aspoň že tak...

[Tom K]

Ale ono na velke stranky neni potreba roota. Viz hugetlbfs ...

[Mandarinka]

Nevím přesně, na co to narazilo, ale ty transparentní velké stránky jim asi moc nefungovaly.

[Sten]

Už od Pentia Pro (v dobách, když jsem ještě psal operační systémy ) existovaly normální stránky (Page), které měly 4 KiB, a velké stránky (Huge Page nebo Page Size Extension), které měly 4 MiB. Na 64bitových procesorech přibyly ještě Large Pages (česky taky velké stránky?), které mají 1 GiB.

Poznámka: windowsí Large Pages jsou ve skutečnosti Huge Pages.

[Luk]

česky taky velké stránky?

Já bych jim říkal „obrovské stránky“

[Mandarinka]

macaté :)

[h0nzZik]

IMHO už od prvního Pentia (1993) bylo možné využívat buď 4KiB, nebo 4MiB stránky. Lineární adresa (32b) se rozdělila na:

a)index do stránkového adresáře (10b), index do stránkové tabulky (10b) a offset (12b).

b)index do tabulky velkých stránek (10b) a offset (22b).

[h0nzZik]

Ještě abych doplnil, u Pentia Pro přibylo PAE a s ním možnost 2MiB a 1GiB stránek. Všechno se dá najít v dokumentaci na webu Intelu.

[luta]

huráá konečně to I/O začal někdo řešit..a co teprv když se zplní ram a dojde ke swapu..to je pak na restart :( i seberychlejší PC je pak zabity

[Sten]

Zaplnění RAM při kopírování brání už dříve přijatý patch pro brzdění I/O operací.

[luta]

to mi nějak uniklo..a už je to ve stable větvi? Protože v Archu s aktuálním kernelem stále stejnej problém a projevuje se stejně jak na 5 let starým notesu s intel c2d tak i na PC s i5

[luta]

ale teď přemýšlím, že to nebylo tak úplně kopírování, ale sežrání RAM procesem při zpracování dat z HDD.. každopádně i tohle by nemělo zalagovat celej OS..třeba jen doba přihlášení do tty je pak na vypití kafe více než dostatečná

[Petr Ježek]

Váš problém nesdílím jako šestiletý archer. Zkuste v sobě probudit admina

[luta]

to by me zajimalo co s tim mam jako delat. hrabat do vm parametru? tohle uz jsem hoodne davno resil i na rootu. uznavam ze pri kopirovani problem nemam. ale zpracovani obrovskeho souboru dat v matlabu ci sezrani 8GB ram jinzm procesem napr virtualkama zpusobi totalni lag. myslim ze pes je zakopan v samotnem kernelu a praci s pameti kde io i data sdili neoddeleny pametovy prostor pokud jsem to kdysi pochopil spravne

[Josef Kufner]

Jo, ten pes je tam zakopaný už hodně dlouho, odhaduju to nějak od dob 2.6.12.

[Jindřich Makovička]

Přesně, ten problém se projevuje několik let, ale s příchodem THP se situace ještě trochu zkomplikovala :)

Teď provozuju na desktopu 3.2-rc3 a odezva během kopírování HDD->USB flash nebo SSD->HDD je mnohem lepší, vidět je to třeba na chrom(e|iu).

[David Watzke]

Jak můžete být šestiletý, když máte v profilu datum registrace starší než 12. 7. 2003?

[egg]

Dřív používal jiné distro?..

[David Watzke]

Rétorická otázka zamýšlená jako žert...

[egg]

Aha, sorry, dneska jsem musel brzo vstávat a jsem zabržděnej jak zápis na disketu. ;)

[Sten]

Tomu se dá zabránit nastavením vhodného swappiness nebo pomocí aplikace memlockd.

[luta]

swappiness mám na 10 a na to druhé když bude čas tak mrknu

[Sten]

Zkuste jej zvednout na 100, mělo by víc swapovat a tím takové aplikace znevýhodnit. Samozřejmě to ale nezachrání všechno, pokud chcete možnost kdykoliv se přihlásit a sestřelit zlobící aplikaci, jinak než pomocí memlockd (který příslušné aplikace zamkne do paměti) to moc udělat nejde.

[luta]

na 100? to se mi zdá hodně přehnané..možná zkusím vrátit na původních 60 nebo kolik to bylo, ale spíš jsem myslel, že u desktopu se výplatí snížit

[Sten]

U desktopu se vyplatí snížit, protože nikdo nepředpokládá, že tam bude nějaká aplikace, která při práci zabere veškerou paměť a bude to vadit, není tam takový nárok na latence. Myslel jsem, že je to server, tam 100 používám.

[Luboš Doležel (Doli)]

protože nikdo nepředpokládá, že tam bude nějaká aplikace, která při práci zabere veškerou paměť a bude to vadit, není tam takový nárok na latence

To je myšleno vážně? U desktopu že nevadí, když vám systém chcípne nebo má sekundovou odezvu?

[Sten]

Latence v jednotkách sekund na desktopu nevadí tolik jako nižší výkon způsobený větším swapováním, typicky tam běží jenom jedno nebo několik pracujících vláken a uživatel prostě chvíli počká, u serveru jsou ale latence nad 10 ms už problém, typicky tam běží desítky až stovky pracujících vláken a při větších latencích to začne zahazovat spojení. A taky serverové disky (resp. pole) bývají mnohem rychlejší, tak mohou více swapovat. Samozřejmě vy nemusíte být běžný uživatel a můžete chtít jiné nastavení (třeba protože tam ladíte webový server), proto to taky jde změnit

[alkoholik]

Jak zacne server swapovat, je to znameni, ze mu mas pridat pamet.

[R]

Cize sa nepredpoklada, ze na desktope pouziva niekto web browser?

[Sten]

Nepředpokládá se, že na desktopu někdo používá deset browserů a chce mezi nimi rychle přepínat.

[kralyk z abclinuxu]

Když máš otevřeno X tabů, v podstatě to tak je...

[ehm ehm]

A co tak 80 browserů? Myslíš si že to nikdo nepoužívá?

[Max]

Souhlas s uživatelem "luta" (zatím ve všem :) ).
Zdar Max

[Andrej]

Velké stránky, pomalé disky a velké prodlevy - to mi pripomina ze na win32 napr. disketove operacie na par (desiatok) sekund efektivne zabijali cely OS

[Marián Kyral]

Například kopírování dat na disketu. To byly doby.

[Mandarinka]

Na linuxu ne? Pokud si vzpomínám, bylo to tím, že disketovku obsluhuje cpu...

[Sten]

Disketovku sice obsluhuje CPU, resp. operační systém (včetně spouštění a vypínání motoru), ale AFAIK ve Windows byl hlavní problém v tom, že spousta toho bylo řešeno synchronně.

[Marián Kyral]

Abych řekl, tak to si už moc nepamatuji, s linuxem jsem začínal v době, kdy už začínal ústup disket. Ale záseky pod win 3.11 a 95 si vybavuji až moc dobře.

[R]

V Linuxe nie (a ani vo Windows rady NT).

[Jimmy]

Poslední windows které z pohledu uživatele "vytuhly" při práci s disketou byly Windows 3.11. Už pod win95 šlo bez problémů formátovat disketu či na ní kopírovat bez znatelného zpomalení stroje. Byl to jeden z výrazných rozdílů mezi win 3.11 a win95 viditelný na první pohled.

[kyytaM]

Neviem, pamatam si to inak. ;)

[Luboš Doležel (Doli)]

Doteď si na to u Win95 pamatuju, jak se to kousalo. Ne jako na Linuxu, že se pomalu ani kurzor nehne, ale systém se nedal někdy používat.

Win 3.x jsem skoro vůbec nepoužíval.

[BrainLess]

Tenhle problem tu bude asi pekne dlouho, nebo nejaka jeho variace. Mam system s 2TB filesystemem na raid5 + 4GB RAM. Na tom 2TB mam cryptoloop ( kryptovanej fs ). Kdyz dam kopirovat data system normalne jede 60 i vice MB/sec ale zacne se zpomalovat, zpomalovat az to spadne na treba i 800KB/sec imho to utluce samo sebe ...

[R]

Takyto problem som raz mal s kopirovanim dat na USB disk. Rychlost tak klesala, ze sa to nikdy nedokoncilo... S nejakym dalsim jadrom to zmizlo.

[Goheeca]

s/pgpgpin/pgpgin/

[jdsulin]

„Někteří lidé asi dají přednost tomu, aby pro svou výpočetní úlohu o 1000 hodinách dostali spousty velkých stránek a trocha čekání na tyto stránky je přijatelná.“ typicky Morton, co si bastli v prikazove radce, jako neberme mu to, chapu, ze z nas desktopovych uzivatelu moc prachu neni a ze dulezita je propustnost a ne nejake kopirovani na USB, ale proboha jsou tu lidi, kteri pouzivaji graficke rozhrani. Nejhorsi je, ze ani nejde o procesor, kdyz provadim IO, tak je uplne jedno jake mam jadro a desktop je v riti. Uplne nejhorsi je, kdyz se to dostane do swapu, jasne IO se tam nedostane, ale ostatni aplikace ano a kdyz se u toho divate na video, tak to je konec. Win7 se naopak vytahly, posledne jsem na 4 jadru cetl 4mi vlakny databazovy soubor, ktery dale zpracovaval a vytizil vsechny 4 jadra a ani jsem to nepoznal, to je to chovani. Jenze s desktopem pri navrhu linuxoveho kernelu nikdo nepocita, ale aspon mame sheduler optimalizovany i pro 1024 procesoru.