abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 00:36 | Nová verze
Vyšel Emacs 24.4. Mezi novinky patří vestavěný webový prohlížeč (M-x eww), podpora více monitorů, celoobrazovkový mód, digitální podpis balíčků, podpora menu v textovém terminálu či nový blokový mód. Více informací v oznámení nebo v historii viditelných změn na stránce projektu.
little.owl | Komentářů: 1
včera 19:57 | Pozvánky
Jana Moudrá Vás 15. listopadu v budově Pilsfree v Plzni seznámí s novým skriptovacím jazykem Dart. Uvidíte spoustu ukázek a bude i prostor pro diskusi. Během následující codelab si můžete nabyté zkušenosti procvičit. Výhodou je znalost skriptovacího/programovacího jazyka, ale není podmínkou – přednáška je určena pro širokou veřejnost. Čas a místo konání později upřesníme na stránce G+ eventu. Přednáška je zdarma, registrace je nutná: … více »
hacup | Komentářů: 0
včera 19:54 | Pozvánky
Coreboot je svobodný firmware, „náhrada BIOSu“. O víkendu v Praze probíhal coreboot hackaton. V úterý večer vystoupí v brmlabu zakladatel Corebootu Ron Minnich.
Jendа | Komentářů: 0
včera 17:17 | Komunita
Po písmenech S, T a U následuje V. Po Saucy Salamander, Trusty Tahr a Utopic Unicorn následuje Vivid Vervet. Mark Shuttleworth v příspěvku V is for Vivid na svém blogu oznámil, že příští Ubuntu ponese jméno Vivid Vervet.
Ladislav Hagara | Komentářů: 5
včera 01:16 | Komunita
Dnes je to přesně 10 let ode dne, kdy vyšla první verze populární distribuce Ubuntu.… více »
tuxmartin | Komentářů: 26
19.10. 20:50 | Zajímavý projekt

Tomáš Solař, autor české knihy Oracle Database 11g – Hotová řešení, nabízí kontrolu databáze Oracle zdarma. Jedná se o bezplatnou službu, která vám může pomoci odhalit slabé místo vaší databáze, aniž byste za to museli platit. Služba je určená všem, kdo využívají databáze Oracle, ale nikterak se o ně nestarají, přestože v nich uchovávají veškerá firemní data. Více se dočtete přímo na webu dba4refence.

Oracle_DBA | Komentářů: 34
18.10. 02:44 | Komunita
V únoru bylo rozhodnuto, že výchozím init systémem Debianu bude systemd (zprávička). Březnový návrh na hlasování o zachování možnosti volby init systému, tj. o tom, že balíček nemůže záviset na konkrétním init systému neprošel. Včera Ian Jackson návrh zopakoval a hlasovat se tentokrát bude. Lucas Nussbaum, vedoucí projektu Debian, podal alternativní návrh: podpora různých init systémů je žádoucí, ale ne povinná. Řeší se také, zda je na hlasování ta správná doba. Debian Jessie by měl být zmrazen 5. listopadu (zprávička).
Ladislav Hagara | Komentářů: 125
17.10. 11:49 | Nasazení Linuxu
Díky kombinaci Raspberry Pi, miniaturního modulárního fotoaparátu Pi a jednoduchého skriptu v Pythonu můžete snímat proměny krajiny nebo třeba východy či západy slunce.
Tadeáš Pelech | Komentářů: 16
17.10. 10:57 | Zajímavý projekt
Docker a Microsoft vydali oznámení o partnerství. Docker bude rozšířen o Docker Engine for Windows Server, služby Microsoftu budou podporovat Docker API.
Michal Vyskočil | Komentářů: 17
17.10. 01:01 | Zajímavý projekt
V dubnu byla vyhlášena soutěž The Hackaday Prize (zprávička) pro vývojáře open source hardwaru. Z přihlášených více než 800 projektů bylo vybráno 50 semifinalistů a následně 5 finalistů. Vítěz bude vyhlášen v listopadu na veletrhu electronica. Hlavní cenou soutěže je výlet do vesmíru nebo 196 418 dolarů v hotovosti.
Ladislav Hagara | Komentářů: 1
Hlasuji z:
 (80%)
 (14%)
 (3%)
 (2%)
 (1%)
 (0%)
Celkem 4489 hlasů
 Komentářů: 50, poslední 12.10. 11:59
Rozcestník
Reklama
Autoškola testy online Levný benzín

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

28. 11. 2011 | Luboš Doležel | Jaderné noviny | 4164×

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

link

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

link

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

link

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

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

28.11.2011 01:35 test test
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 :-)
28.11.2011 08:23 Michal Kubeček | skóre: 69 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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) avatar 28.11.2011 21:12 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Jasně, pardon.
29.11.2011 13:12 salam
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Mně se nezdá ani to přemýšlí, co třeba Několik vývojářů si nicméně myslí?

Luboš Doležel (Doli) avatar 29.11.2011 14:23 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
V originále je are wondering, nikoliv think.
belisarivs avatar 29.11.2011 16:37 belisarivs | skóre: 22 | blog: Psychobláboly
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Hm.

Jirka Bourek uz nepreklada?

At jaderne novinky preklada kdokoliv, odvadi sakra dobrou praci.
IRC is just multiplayer notepad.
Luboš Doležel (Doli) avatar 29.11.2011 17:32 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Jirka už je nepřekládá, proto jsem to po něm převzal já. Takže děkuju :-)
30.11.2011 12:40 salam
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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) avatar 2.12.2011 18:17 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Není to to samé?
28.11.2011 10:13 gm
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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?
28.11.2011 10:22 gm
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
tak jsem zkusil dostudovat, hmm zajimave ... vzdy jsem mel pocit, ze strankovani tu je kvuli fragmentaci ...

Luk avatar 28.11.2011 12:11 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 ;-)
Komu se nelíbí mé blogposty, ať je nečte. Opravdu to není povinné.
28.11.2011 22:25 Mandarinka
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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...

kralуk avatar 29.11.2011 11:44 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 29.11.2011 12:21 michich | skóre: 50 | blog: ohrivane_parky
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Na mlock() nemusíš být root, ale musíš se vejít do limitu (ulimit -l, memlock v limits.conf).
kralуk avatar 29.11.2011 14:30 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Aha, díky, tak fajn, aspoň že tak...
29.11.2011 14:19 Tom K | skóre: 20
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Ale ono na velke stranky neni potreba roota. Viz hugetlbfs ...
echo -n "u48" | sha1sum | head -c3; echo
3.12.2011 23:57 Mandarinka
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Nevím přesně, na co to narazilo, ale ty transparentní velké stránky jim asi moc nefungovaly.
28.11.2011 12:55 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 28.11.2011 17:19 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
česky taky velké stránky?
Já bych jim říkal „obrovské stránky“ ;-)
Komu se nelíbí mé blogposty, ať je nečte. Opravdu to není povinné.
3.12.2011 23:57 Mandarinka
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
macaté :)
28.11.2011 21:27 h0nzZik | blog: Osel a stín
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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).
28.11.2011 21:32 h0nzZik | blog: Osel a stín
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 28.11.2011 12:49 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

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

28.11.2011 12:57 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Zaplnění RAM při kopírování brání už dříve přijatý patch pro brzdění I/O operací.
luta avatar 28.11.2011 13:43 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

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 avatar 28.11.2011 13:46 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

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á

28.11.2011 14:44 Petr Ježek | skóre: 9
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Váš problém nesdílím jako šestiletý archer. Zkuste v sobě probudit admina :-)
Archlinux for your comps, faster running guaranted!
luta avatar 28.11.2011 15:31 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 28.11.2011 15:45 Josef Kufner | skóre: 64
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Jo, ten pes je tam zakopaný už hodně dlouho, odhaduju to nějak od dob 2.6.12.
Hello world ! Segmentation fault (core dumped)
28.11.2011 15:58 Jindřich Makovička | skóre: 9
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 28.11.2011 19:42 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Jak můžete být šestiletý, když máte v profilu datum registrace starší než 12. 7. 2003?
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
egg avatar 30.11.2011 09:48 egg | skóre: 20 | Praha Podolí
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Dřív používal jiné distro?..
David Watzke avatar 30.11.2011 10:00 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Rétorická otázka zamýšlená jako žert...
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
egg avatar 30.11.2011 11:48 egg | skóre: 20 | Praha Podolí
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Aha, sorry, dneska jsem musel brzo vstávat a jsem zabržděnej jak zápis na disketu. ;)
28.11.2011 17:53 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Tomu se dá zabránit nastavením vhodného swappiness nebo pomocí aplikace memlockd.
luta avatar 28.11.2011 18:56 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

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

28.11.2011 19:35 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 28.11.2011 19:44 luta | skóre: 21 | blog: muj_blok | Prostějov/Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O

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

29.11.2011 01:11 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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) avatar 29.11.2011 09:32 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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?
29.11.2011 17:19 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 :-)
30.11.2011 10:35 alkoholik | skóre: 32 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Jak zacne server swapovat, je to znameni, ze mu mas pridat pamet.
29.11.2011 12:07 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Cize sa nepredpoklada, ze na desktope pouziva niekto web browser?
29.11.2011 17:19 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Nepředpokládá se, že na desktopu někdo používá deset browserů a chce mezi nimi rychle přepínat.
kralуk avatar 29.11.2011 17:49 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Když máš otevřeno X tabů, v podstatě to tak je...
29.11.2011 20:19 ehm ehm
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
A co tak 80 browserů? Myslíš si že to nikdo nepoužívá?
Max avatar 28.11.2011 15:59 Max | skóre: 61 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Souhlas s uživatelem "luta" (zatím ve všem :) ).
Zdar Max
Měl jsem sen ... :(
28.11.2011 16:06 Andrej | skóre: 8
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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
Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
Marián Kyral avatar 28.11.2011 18:49 Marián Kyral | skóre: 28 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Například kopírování dat na disketu. To byly doby.
28.11.2011 22:28 Mandarinka
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Na linuxu ne? Pokud si vzpomínám, bylo to tím, že disketovku obsluhuje cpu...
29.11.2011 01:12 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 avatar 29.11.2011 09:46 Marián Kyral | skóre: 28 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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.
29.11.2011 12:09 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
V Linuxe nie (a ani vo Windows rady NT).
29.11.2011 20:06 Jimmy
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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.
29.11.2011 22:37 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
Neviem, pamatam si to inak. ;)
Luboš Doležel (Doli) avatar 30.11.2011 00:47 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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.
29.11.2011 10:04 BrainLess
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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 ...
29.11.2011 12:11 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
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.
29.11.2011 16:36 Goheeca
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
s/pgpgpin/pgpgin/
3.12.2011 18:43 jdsulin
Rozbalit Rozbalit vše Re: Jaderné noviny – 17. 11. 2011: Zasekávání procesů při velkém I/O
„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.

Založit nové vláknoNahoru

ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.