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

[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.