Opraven problém s odezvou Linuxu při velké I/O zátěži?

Phoronix.com informuje o nové záplatě, která by měla řešit některé problémy s odezvou systému při velkém I/O zatížení a nedostatku místa v RAM. Patch je dostupný na lkml.org a prý skutečně funguje.

5.8.2010 00:21 | David Watzke | Nová verze

Komentáře

[pepe_]

Žeby konečně použitelný desktop ?

[jiřík]

No, nedávno jsem kopíroval z externího NTFS usb disku na Windows 7 asi 12 GB hudby, tedy hodně moc relativně malých souborů.

Ačkoliv mám docela výkonný notebook, tak ani na Windows s tím moc pracovat nešlo ...

[David Watzke]

Jedna věc je chtít od toho nemožné a jiná věc chtít od toho to, co to klidně zvládne. Určitě je blbost abys bombardováním jednoho disku znepřístupnil celej systém (i ostatní disky, který se flákaj).

[pavlix]

Myslím, že nesdílíme stejnou definici slova nemožné.

[David Watzke]

Asi jsem se jenom špatně vymáčk, protože jsem si docela jistej, že sdílíme

[pavlix]

Může být :).

[Let_Me_Be]

To je spis problem USB a ovladacu. Tady slo o to ze I/O dokazalo odrovnat system natolik, ze i kdyz bylo totalne volne CPU tak se s tim systemem nedalo vubec delat.

Musim rict ze v OpenSuSe 11.2 se to moc neprojevuje, ale 11.1 tim trpelo strasne.

[Let_Me_Be]

Hmm, tak koukam ze tohle je zase neco noveho. Ale tento obecny problem tam uz je pekne dlouho.

[peto]

aj 11.3 s tym ma problem.. Preto ma oprva tesi.

Ja som bol v tom, ze je to cisto o disku, ale potom som zistil , ze sa casto vypinaju kompozitne efekty, z dovou, ze spomaluju system a odozva bez nich bola lepsia... Takze sa I/O netyka len diskov

[frEon]

ja si pamatuju, jak kdyz jsem pred lety opustil windows, tak jsem byl nadseny prave z toho (a z mnoha jinych veci), ze kdyz sem neco kopiroval, tak krom hluku z disku sem o tom vubec nevedel. dneska uz je to jak na tech vidlich....

[Tom K]

Aspon vidis o kolik jsou windows napred

[Jendа]

Nešlo by to opravit?

[J. M.]

Celé měsíce jsem zkoušel jsem všechno možné, včetně těch rad v té diskusi, i jiných, dokonce i výměnu počítače za jiný, ale nepomáhá vůbec, vůbec nic. Takže jestli to už teď opravdu (ne jak už se za poslední roky tisíckrát „teď už zaručeně“ psalo) vyřešili, tak milionkrát hurá. Konečně po mnoha letech použitelný Linux.

[pht]

Že by konečně opravili křápojádro? Zázrak.

[Grunt]

Ne. Zázrak by byl, kdyby aspoň jeden ze zdejších kecálků/věčných stěžovatelů nebo rádobykritiků u kterého lze tento problém reprodukovat se pustil do profilování jádra nebo jiné činnosti pomocí které by se dalo zjistit, které funkce v případě tohoto efektu spotřebovávají procesorový čas/drží zámky/atd. Jediná oprávněná kritika v OSS světě je patchem, bug reportem, core dumpem, log dumpem, call grafem, …

[Ladicek]

Jediná oprávněná kritika v OSS světě je patchem, bug reportem, core dumpem, log dumpem, call grafem, …

Ne.

[Grunt]

Ne.

Ano.

[xm]

Ten bug byl reportován na jaderné Bugzille již koncem roku 2008 (Large I/O operations result in poor interactive performance and high iowait times, je tam u něj mega-dlouhá diskuze, ale řešení až do teď žádné (pokud tento patch opravdu řešením je, ještě jsem to netestoval).

Na Ubuntu Launchpadu to bylo reportováno ještě dřív, už někdy v roce 2007 (Heavy Disk I/O harms desktop responsiveness) a taktéž je tam k tomu mega-dlouhá diskuze.

Upřímně nechápu, jak tak děsivý bug mohli vývojáři kernelu tak dlouho prakticky ignorovat (i přes milion reportů v diskuzi pod tím bugem) :-/

[Grunt]

Ten bug byl reportován na jaderné Bugzille již koncem roku 2008, je tam u něj mega-dlouhá diskuze, ale řešení až do teď žádné.

Ale aniž bych to celé četl, tak tam vidím spousty statistik a různých dalších údajů, když si to jen tak proletím a schválně by mě zajímalo kolik tam bude nadávek jako pod touto zprávičkou o tom jak nikdo nic nedělá a jak je všechno křáp. Což je ten rozdíl o kterém se tady bavím.

Na Ubuntu Launchpadu to bylo reportováno ještě dřív, už někdy v roce 2007 (Heavy Disk I/O harms desktop responsiveness) a taktéž je tam k tomu mega-dlouhá diskuze.

To jsem také jen v rychlosti proletěl, ale to už se naopak začíná podobat zdejší diskusi.

Upřímně nechápu, jak tak děsivý bug mohli vývojáři kernelu tak dlouho prakticky ignorovat (i přes milion reportů v diskuzi pod tím bugem) :-/

Třeba protože se jim to nedaří reprodukovat? Stejně jako mně? (A to už jsem vyzkoušel všechny zde uváděné tipy včetně strees -d 1) A třeba protože se nikdo u koho se to reprodukovat podařilo neobtěžoval se zasíláním užitečných údajů a jen se o tom vyblil do blogu? Jediné rozumné vysvětlení totiž je, že vývojáři jádra si asi vzali dovolenou, vyvalují se někde u moře na pláži a kašlou na všechny ty ubožáky uživatele, ne? V mém případě se to stalo jen jednou a to když jsem se pokoušel kopírovat na vadný USB disk.

[Jendа]

Zkus

for i in `seq 1 5`; do
  dd if=/dev/zero of=/tmp/bigfile$i bs=1M count=700 conv=fsync &
done

(případně víc vláken a větší soubory)

Mně zatuhne systém (2.6.32) tak strašně, že mám problém to i killnout.

Atom N270, 1 GiB RAM, dirty_ratio=10, dirty_background_ratio=5, swappiness=0

[Grunt]

Nic. Ale už jsem asi přišel na to proč. Běžím na jádře z Meerkata. Když nabootuju standardní 2.6.32-24-generic, tak už se začíná pomaloučku po zaplnění keše kousat myš i výstup ze zvukovky. No na druhou stranu se mi ve zdrojácích (teda jestli jsou opravdu od jádra na kterém běžím…u Ubuntu Kernel Teamu by se z toho také jeden mohl zbláznit) nikde nedaří najít should_reclaim_stall(), takže nevím.

[Jendа]

Příloha:

• config-2.6.32-5-686 (109061 bytů)

Třeba je to Ubuntu nějak jinak zkonfigurované…

(teď, když jsem rozbaloval balíček, abych z něj vytáhl config, se to zase seklo)

[Grunt]

Příloha:

• config.diff (65498 bytů)

Těžko říct:

diff 161381-config-2-6-27750.32-5-686 /boot/config-2.6.35-020635-generic > config.diff

No teď jsem se snažil patchovat to 2.6.32 jádro a zjistil jsem, že tam mají pro změnu úplně něco jiného než co očekává diff:

/*
		 * If we are direct reclaiming for contiguous pages and we do
		 * not reclaim everything in the list, try again and wait
		 * for IO to complete. This will stall high-order allocations
		 * but that should be acceptable to the caller
		 */
		if (nr_freed < nr_taken && !current_is_kswapd() &&
		    lumpy_reclaim) {
			congestion_wait(BLK_RW_ASYNC, HZ/10);

			/*
			 * The attempt at page out may have made some */

Takže mě čeká nějaká ta hodinka prohrabávání se Ubuntími patchi.

[Delaunay]

Taky mě to při aplikaci patche nepříjemně překvapilo. Nicméně z toho diffu i názvu předmětu na LKML je jasné, že to bylo aplikováno vůči -mm větvi (mmotm).

Viz http://forum.root.cz/index.php?topic=770.msg4748#msg4748.

[Grunt]

Jo, vím že je to vůči mmotm, ale čekal jsem že to tam nacvakám ručně. Je to přidání jedné funkce a přesměrování parametrů do ní. No bohužel to má trošičku jiné názvosloví a radši nebudu pokoušet osud. O to víc, když to má už jinak i vanilla a cpát přes sebe Ubuntu patche a mmotm je také práce spíš pro odvážlvce (především když to funguje dobře i bez pacthe).

[Jendа]

Přiznám se, že nechápu, jak může fungovat nastavení swappiness na 100 (zmiňováno v posledním komentáři jako oprava). Vždyť to způsobí odswapování všech aplikací.

[Grunt]

pokud tento patch opravdu řešením je, ještě jsem to netestoval

Jinak tento patch řeší zablokování se navzájem špatně umístěnou podmínkou při zápisu dirty pages, což se děje třeba při volání sync(2), když je uklízí ten jaderný démon a nebo možná ještě při swapování. Ale rozhodně to není řešení všech problémů světa. A rozhodně ne v případě, že jde o kopírování médium, médium za pomocí DMA mechanismu a jiných podobných situacích jak se mi tady daří číst. Takže pokud se to děje u vás i nadále, rozhodně na nic nečekejte. Vaše problémy za vás nikdo řešit nebude.

[pht]

kecálků/věčných stěžovatelů nebo rádobykritiků

Jen pro upřesnění, ten zápisek se týkal jádra kolem 2.6.30, které kromě toho, že bylo pomalé, bylo ještě asi tak desetkrát pomalejší než dnes.

A pokud jste to přehlédl, tak zápisek také opravuje postup opravy.

Jediná oprávněná kritika v OSS světě je patchem, bug reportem, core dumpem, log dumpem, call grafem, …

Nějakým činem předpokládáte, že všichni uživatelé OSS jsou programátoři které navíc každá chyba v softwaru vzrušuje natolik, že věnují několik probděných nocí hledáním opravy. Mýlíte se.

[pavlix]

Nějakým činem předpokládáte, že všichni uživatelé OSS jsou programátoři které navíc každá chyba v softwaru vzrušuje natolik, že věnují několik probděných nocí hledáním opravy. Mýlíte se.

Díky, že tuto často opomíjenou věc v diskuzi připomínáš.

[hehek]

On ten problem neni ani tak v kernelu jako v tom samotnym desktopovym prostredi. KDE a dalsi jsou opravdu nechutne disk-bound, s tunou konfiguracnich souboru a synchronnima operacema nad nima.

[J. M.]

Blbost. To se projevuje v jakémkoli prostředí, i primitivním.

[J. M.]

A samozřejmě na jiném jádře (FreeBSD, NetBSD) se to neprojevuje. Čili chyba je jednoznačně v Linuxu.

[tsLnox]

Souhlas - openbox, tint2, conky. Nic víc

[pht]

Blbost. To se projevuje v jakémkoli prostředí, i primitivním.

To sice jo, ale pokud máte prostředí, ve kterém každá kravina hrabe na disk, tak je to jenom horší.

Například když začnete v prohlížeči zadávat adresu tak prohlížeč začne hrabat do databáze záložek a historie na disku, aby nabídl auto-doplnění. Pokud tohle hrábnutí trvá půl minuty a prohlížeč je po celou tu dobu tuhý tak to může být dost k nasrání.

[Jiří]

Má to něco společného i s totálními pády notebooku při delším kopírování z usb hdd (xfs) v KDE 4.4.4? Totálním pádem myslím to, že zhasne i kontrolka napájení a musím odpojit/připojit adaptér.

[Jendа]

To bude HW. Přehřívání?

[Andy]

+1

[Jendа]

Že je to Acer Aspire 56xx?

[Jiří]

Acer Extensa 5204. Ještě to zkusím s externím napájením hdd. Dík.

[Jendа]

Nemůže to být tímhle? Dědovi se totiž dělo úplně totéž, pomohlo vzít mempat a do nějakého místa v paměti (lze vyčíst z toho skriptu) napsat nějaké šílené číslo (lze vyčíst z toho skriptu ).

[vain]

Do řiti o čem mluvíte? =) Kopíruji denně tunu sraček ze samba serverů k sobě a nic takového nepozoruji. Jak se to dá reprodukovat? Co vše musí být "splněno"?

[tsLnox]

Splněno? Nebýt lucker :-P

[JS]

Pisou malo pameti. Kopirovani zabira jen cache, to asi nebude ten problem.

[vain]

Aha, tak to je možné, mám tady 4GiB RAM sotva kdy využité.

[Let_Me_Be]

Na OpenSuSe 11.1 se to projevovalo naprosto stabilne pri kopirovani SWRAID->SWRAID. Nebo pri silnem sitovem toku ukladanem na disk.

Ted uz jsem to delsi dobu nezazil (alespon ne v te zakladni forme kdy je cele PC desitky minut uplne mrtve), ale ted se mi pro zmenu nelibi RAID<->RAID rychlost kopirovani.

Jinak pamet taky 4G.

[Jendа]

Taky po síti, je-li jenom 100Mb/s, se to asi tak neprojevuje. Ale Sempron na 1,8 GHz dokázaly spolehlivě odrovnat dva rsyncy po 100 Mb/s - rsync je náročnější než Samba, protože kromě přenosu počítá delty.

A Atom N270 (s HT) zase zatuhával, když melt renderoval ve třech vláknech video. I když jsem mu nastavil nejnižší prioritu, tak ostatní aplikace byly sotva použitelné. Nakonec jsem to zastavil a nechal do doběhnout přes noc, kdy nepoužitelnost počítače nikomu nevadila.

[Luboš Doležel (Doli)]

Na Gigabitu mi velké přenosy odrovnávají Linux bohužel docela běžně Občas to pak řve něco o tom, že procesy visí příliš dlouho ve vm_něco(). Částečně pomohlo přidat RAM.

[Zdenek]

A mate sitovou kartu nebo realtek?

[JoHnY2]

Za 8111x by Realtek zaslouzil pres hubu. Mam s nima jen ty nejhorsi zkusenosti. Bohuzel je vsichni vyrobci cpou na vsechny desktopovy desky.

[Ondrej 'SanTiago' Zajicek]

Zkusenosti jakeho typu?

[JoHnY2]

Ze zacatku problemy s driverama v linuxu (ale to uz je dlouho). Mam tu aktualne dve 8111 a s obema neco je. Jedna zacne po nespecifikovanym mnozstvi prenesenejch dat ztracet packety az packet loss vyleze k 90%. Staci ifdown, ifup nebo zakazat a povolit pripojeni ve widlich a je zase treba i na mesic (nekdy taky na dve hodiny) v poradku. Druha ma problemy s udrzenim gigabitu na dratech, kde vsechno ostatni (i ta druha 8111) fungujou.

Mel jsem i pres stejnou CPU nenazranost hrozne rad 8139, protoze to byly karticky za par korun a nikdy jsem s nima nemel potize. Maximalne nejaka proste zdechla, jenze to je v pohode. Mrtvej HW se vyhodi a nahradi. Nejvetsi hruza je podivny chovani, coz mi prave ve vrchovaty mire dopravaj 8111 a proto je nesnasim.

[VSi]

Nejhorší je, že tyhle problematické Realtek Gb síťovky jsou na většině desktopových základních desek. Snad kromě těch od Intelu nebo těch z dražšího segmentu. Naštěstí i v obyčejných PC třeba od HP bývají aspoň Broadcom NetXtreme nebo Intel.

Na druhou stranu jsou pro ty Realteky celkem slušné ovladače v jádře. To takové Atheros Gb L1E / L1C už jsem viděl v pár strojích (desktop desky i notebooky) a ovladače jsou ještě ve 2.6.34 označeny jako experimental (nevím, jestli se to od té doby změnilo), což jsem nedávno na jednom notebooku pocítil a stálo to pár hodin času (no, možná to není chyba těch ovladačů, ale pofidérní HW, ve Windows je to ale OK) ...

[Luboš Doležel (Doli)]

Ozkoušenej atl1 i e1000, obojí to samý.

[Heron]

CentOS 5.5 64b (kernel 2.6.18), saturovaný gigabit (104 MB/s), kopírování mezi SW RAID poli a do toho rsync na další disk a žádné záseky ničeho se nekonají (za ta léta s linuxem jsem popisovaný hrůzný stav v této diskusi ještě ani nikdy neviděl -- snad ani neuvidím). Doufám, že toto řešení backportují do CentOS 6.0 (2.6.32), protože linux ve stavu popisovaný v této diskusi by byl pro mě zcela nepoužitelný .

[Rovano]

Slavný hyperthreading v praxi.

[Luboš Doležel (Doli)]

Já jsem tam někde četl, že to opravuje chybu zavedenou před rokem. Jenže Linux je v tomhle pěkně na prd mnohem dýl než rok.

[Bedňa]

Čo je na prd? Nejak som z toho komentára mimo.

[J. M.]

Linux. A ta chyba je tam skutečně již řadu let (myslím, že od jádra 2.6.18, rok 2006), takže jestli opravdu opravili jenom něco z posledního roku, tak to určitě není ono.

[Bedňa]

Bude to závislé aj od HW a FS, lebo mne sa skór spomalí práca s diskom, ale ale odozvy systému sú stále v pohode a myslím že nie som sám, podľa toho čo čítavam k tejto téme. Dodám že fachám na ReserFS.

[JVid]

Přesně tak, já od začátku používání Linuxu jedu na Reiser4 a když např. kopíruji čtyři různé soubory naráz, tak se desktop trochu zpomalí, to ano, ale nic hrozného. Nedávno jsem ale na svůj počítač ze zvědavosti nainstaloval Debian a instalátor mi Reiser4 nenabídl, tak jsem zvolil ext4. Při obyčejném spouštění Firefoxu se trhalo všechno, včetně kurzoru myši, stejně jako při jakékoliv jiné operaci vyžadující přístup k disku. Nejdřív jsem kontroloval, zda funguje DMA, ale v tom problém bohužel nebyl. Nejhorší je, že někdy (mnoho malých souborů) ani ionice nepomůže, nevím proč.

[Bedňa]

Ionice ti nemusí pomôcť, za to môže rozbitý plánovač, ale čoskoro by sa to malo zlepšiť. Tak s tým Reiser kontra ext4 si pekne zavaril, za to ťa tu zožerú Ja to tvrdím stále, našli sa aj nejaké hlasy od jadrákov, ale v mailing listoch to nebolo, asi som na to natrafil niekde v blogoch, čo ma štve že to už nemôžem nájsť.

[xm]

Nechci vám kazit radost, ale filesystemem to opravdu není. U různých filesystemů se ten problém projevuje trošku jinak (tu více, tu méně), ale pořád je přítomen. Osobně mám vyzkoušeno, že i s reiser4 se to dokáže velmi drsně projevit (i když s ext3/4 je ten problém více viditelný). Jak jsem psal níže, jde o dlouhotrvající problém hluboko v kernelu.

Jestli mi nevěříte, zkuste si spustit program stress -d 1 když máte zabranou větší část paměti (klidně ještě nějaký ten gigabajt může být volný, stejně se to projeví). Pokud se to u vás neprojeví, patříte mezi to malé množství šťastlivců, jejichž systém z nějakých důvodů (zcela jistě souhra více věcí) tímto problémem tak netrpí.

Btw. na některých systémech pomáhá vypnout swap (zcela vypnout, nastavení swappiness na 0 bohužel větší vliv nemá), tzn. pokud vůbec nemáte swap, může to být jeden z důvodů proč se to u vás neprojevuje.

[xm]

Ještě doplnění - obecně lze říci, že na zasažených systémech se problém projeví vždy při kopírování souborů velkých natolik, aby došlo k zaplnění page cache.

[JVid]

Jistě, že problém s výměnou FS nezmizí (mimo jiné i proto, že každý počítač má své HW limity), ale dobře navržený writeout algoritmus udělá vážně hodně.

Má vůbec ext4 concurrent flushing? Připadá mi totiž, že ve chvíli, kdy se na ext4 disk něco zapisuje, je to jediná činnost, kterou v tu chvíli driver může provádět a veškeré pokusy o čtení ve stejnou dobu budou odloženy na neurčito, přestože každý ví, že čtení má mít prioritu vyšší. Navíc se to dá snadno vyřešit – zpracováváním požadavků ve vláknech. Dokud byl ve výchozím nastavení extů writeout natvrdo po pěti sekundách, asi se to tolik neprojevovalo, ale teď může být ve frontě klidně i několik GB špinavých stránek, a když člověk minutu nemůže hnout s kurzorem a přestane mu hrát hudba, tak vážně uvažuje nad použitím resetu.

[JVid]

Tak jsem zkompiloval ten stress a už mi to tu běží. Konfigurace je Atom 1,3 GHz, disk SATA 2,5" (klasický netbook s Poulsbem). Navíc se mi na pozadí kompiluje Wine 1.3.0 a v popředí hraje Flash z Youtube. Bez postřehnutí až do -d 15, při -d 25 se začne sekat ten Flash, i když nehýbu myší, okolo -d 50 už je to nesnesitelné (tím myslím to, že při psaní tohohle příspěvku se písmena objevují až po čtvrt sekundě, ale kurzor pořád jezdí plynule). To je tak asi to, co by člověk čekal od Atomu.

Dokonce i když si hraju s ostatními přepínači, systém se nezasekne tak, aby ztratil přijatelnou dobu odezvy (do 3 s od kliku na něco, co je normálně okamžité), až do nastavení typu vše na 20. Když dám vše na 100, tak už kurzor „skáče“ po cca. tří až čtyř sekundách.

[luta]

mě na Archu zabilo desktop už -d 5 (Gnome,noťas Core2duo 1.66ghz,3GB ram,100GB/7200ot IDE) aspoň že mi furt hrála hudba do sluchátek když už jsem musel čekat i na killnuti

[Marek Niklíček]

Zaujímavé. Ja som to nechal spustené s -d 100 v Arch Linuxe x86_64 s jadrom 2.6.35 a ešte stále to beží a môžem normálne pracovať (všetko sa zatiaľ vykresľuje a reaguje okamžite). Doteraz to zapísalo 16 GiB na HDD a budem to musiet vypnúť, lebo ešte dostanem ENOSPC (No space left on device). :D Všetky partície sú na BTRFS so zapnutou transparentnou kompresiou (zlib_deflate) a momentálne mi tu beží KDE 4.5 RC3, KTorrent, niekoľko IM programov, Konsole a Chromium. Konfigurácia notebooku je: Intel Core i5 @ 2,2 GHz, 6 GiB RAM, 640 GB HDD (5200 RPM), ATI Mobility Radeon HD 5650 1 GiB.
Avšak mám aj opačnú skúsenosť a to s predošlým notebookom, ktorý mal len 2 GiB RAM a pomalý 160 GB HDD. Bol tam Arch Linux x86_64 a občas to začalo swapovať bez prestávky niekoľko desiatok minút, až som musel počítač restartovať pomocou magic key. Výrazne sa ale situácia zlepšila, keď som tam ReiserFS 3.6 vymenil za BTRFS so zapnutou transparentnou kompresiou. Tam by sa tento patch veľmi hodil, ale zatiaľ som ho na žiadnom počítači nevyskúšal.

[luta]

já měl swap prázdnej..už jsem to řešil i v diskuzi kdysi na rootu..dělo se mi to i ve starým ubuntu dva roky zpět, hodně při přelejvání dat na externí HDD jen teď nevím kterým směrem (hodně HD filmy 4GB+). Buď už teď tolik nekopíruju nebo se to trochu zlepšilo, ale ten program mi to zabil pěkně..CPU 20 30% swap na nule, myš se nesekala ale odezva šla pomalu do kytek..ještě z dříve mám vyzkoušené, že když sleduju třeba přes lxtask množství zabrané ram i s cache, tak jakmile dosáhne cache konce RAM (prostě ji vyžere třeba 2GB) tak se to začne dít, spuštěné programy mají špatnou odezvu, nacachované programy letí z ramky a vše se při dalším spouštění tahá znova z HDD, který má kupu práce a tak je to začarovanej kruh..

[Chytrex]

Hmm nic takového nepozoruju.. Předtím sem měl singlecore A64 2,4GHz 1GB RAM a teď Intel i7, 4GB RAM a 2,5TB kapacita disků.. Na předchozím compu byl debian stable s distrib jádrem (2.6.26) a ted mám poslední jádro z lenny backportů (2.6.32) a prostě se mi tohle neprojevuje.. Asi kopíruju malé datové objemy.. (max 7gb fajly). Spíš bych řek, že tohle bude bug závislý na HW.. Jinak FS který používám je téměř výhradně EXT3, na partitioně pro FTP JFS..

[Jendа]

Pusť si rsync mezi dvěma šifrovanými disky nebo pusť render nějakého videa ve více vláknech a zkus přitom browsit nebo i jenom ťukat do terminálu.

[J. M.]

Nebo třeba pohnout kurzorem myši. Když jsem na svém starším, pomalejším počítači kopíroval několikasetmegabajtový soubor na disk (jak interní, tak externí USB), tak prostě po celou dobu kopírování, klidně třeba 5 minut nonstop, byl počítač úplně, ale doslova úplně tuhý. Kurzorem myši celé minuty nešlo pohnout ani o pixel, dokonce i měřič vytížení se přestal aktualizovat, stejně jako další dění na obrazovce, žádná tlačítka na nic nereagovala, vstup z klávesnice zablokován, do konzole nešlo napsat ani písmenko.

Teď na novějším počítači je to lepší, ale pořád špatné.

[Matlák]

no teď zrovna synchronisuju 14G obrázkový adresář mezi ntb (core2duo) a stolním strojem (athlonxp). Oba stroje mají disky šifrované TrueCryptem... k tomu mi na tom athlonxp jede dvb-t a internetové rádio a je to ok, myš se hýbe a do prohlížeč jde psát ... možná to souvisí s usb, na flashce se to ale neprojevuje....asi jsem ten lucker

[xm]

Projevuje se to např. i při kopírování mezi dvěma samostatnými interními SATA disky (pozorováno na více strojích různých konfigurací). Holt jste štístko

[Nicky726]

No to jsem zvědavý. Sice mi přijde, že se to s posledními jádry trochu zlepšilo, ale i tak to není ono. Tak doufejme, že se to dostane do upstreamu.

[Sten]

Aha, tak to je ten problém, proč při instalaci tří virtuálů v KVM v Xubuntu zatuhly Xka. Já myslel, že spadly, a ono se to jenom zpomalilo

[SAM:]

Zkusil někdo ten patch použít? Mně to nejde a nikde jsem se nedočetl, vůči jaké verzi jádra to je.

[Max]

Já si myslím, že to bude proti 2.6.34 (vzhledem k tomu, že chlapec reaguje na bug v 2.6.34rc3), nebo proti aktuální rc verzi 2.6.35. Patchovat by se měl jen jeden soubor : "mm/vmscan.c". Je to krátký patch, takže ten soubor můžeš upravit i ručně.
Zdar Max

[vlastikroot]

Divný, že já vubec žadný problémy nepozoruju, vlastně jsem v životě neviděl, aby se systém při I/O nějak výrazně zpomaloval. Teda až na USB, tam je to ale jasný, když to vyžere celej CPU jen na obsluhu USB.

[Václav "Darm" Novák]

Šťastný to člověk, mě už to také udělalo mnohokrát.

[stativ]

+1. Tři různé počítače. Ale na cizím jsem to viděl.

[Marián Kyral]

Na gentoo se mi to občas stává, když se rozbalují zdrojáky kernelu, nebo třeba openoffice - systém se na pár sekund úplně zasekne, ani obrazovka se nepřekresluje. Zajímavé je, že to není po celou dobu toho rozbalování.

[Jendа]

Asi když se vyprazdňuje cache z RAM na disk? U ext3 to tuším defaultně bylo každých 5 sekund.

[Ondrej 'SanTiago' Zajicek]

Teda až na USB, tam je to ale jasný, když to vyžere celej CPU jen na obsluhu USB.

To mas asi nejake rozbite USB. Ja mam pri sekvencnim cteni z disku pres USB cca 20 % vytizeni CPU pri 30 MB/s, oproti tomu pri sekvencnim cteni disku pres SATA cca 40 % vytizeni pri 90 MB/s. Procesor slaby Atom. Tedy pres USB to ma jen 1.5* relativne vetsi procesorove vytizeni nez pres SATA.

[vlastikroot]

Rozbité USB asi bude, ale zatím jsem neviděl žadné nerozbité. Problém s USB mám jak na aceru 5310, na thinkpadu T41, na VIA desce s socket A procesorem, na intel desce s ICH5 (nebo co to je za čipset) a pentium 4. Všude jde CPU na 100% a další procesy pak zpomalují přenos (takže kompilace wine + kopírování na flashku = 1MB/s).

[Marek Niklíček]

S tým súhlasím. Ja tu mám k dispozícii 5 počítačov s Arch Linuxom, ktoré sú po hardvérovej stránke odlišné a jednoducho zápis na ľubovolný USB kľúč je veľmi pomalý (oproti Windows) + zaťažuje 1 jadro procesora na 100%. Avšak mám pocit, že sa to s poslednými jadrami trochu zlepšilo, ale pamätam si i na dobu, kedy bol zápis rýchly (ešte rýchlejší, než na Windows). U mňa sa to drasticky zhoršilo pred približne 2 rokmi.

[stativ]

Pokud mountuješ pomocí něčeho založeného na HALu (třeba mountování v KDE), tak je to problém nastavení HAL. V defaultu je totiž nastaveno sync, takže odpojení je sice rychlé, ale zápis nehorázně pomalý.

[Marek Niklíček]

HAL u mňa mountuje s voľbou async a u FAT ešte s flush. Skúšal som rôzne súborové systémy, voľby sync, async, flush, bez flush (pri FAT) a tak podobne, ale nepomohlo nič.

[xm]

V defaultu rozhodně sync nastaveno není. Nastaveno je pouze flush, což by rozhodně nemělo být tak agresivní (už z toho důvodu, že sync dokáže spolehlivě odrovnat staré či levné flashdisky s blbým wear levelingem). Vliv na rychlost zápisu to určitě mít bude, ale jak velký, to je otázka. Muselo by se to změřit

[stativ]

OK, spletl jsem se. Nicméně z diskuse na mailing listu Archu si pamatuju, že vypnutí zápis zrychlilo.

[xm]

Jestli se ovšem nemýlím, tady byla řeč o _čtení_ z flash disku (které je u některých lidí pomalé), nikoliv jen o zápisu. Na rychlost čtení by ta volba neměla mít vůbec žádný vliv.

[stativ]

… jednoducho zápis na ľubovolný USB kľúč je veľmi pomalý…

Já řešil jenom zápis. Samozřejmě, že na čtení to vliv mít nebude.

[xm]

Aha, máte pravdu, zmýlil jsem se.

[Marek Niklíček]

Ja napríklad s čítaním problém nemám (na každom počítači cca 20-30 MiB/s), ale zápis je len 2-4 MiB/s (vo Windows to bývalo aspoň 11 MiB/s). Bola doba, kedy to fungovalo normálne, potom zase doba, kedy sa zapisovalo maximálne 1 MiB/s a v poslednej dobe pozorujem mierne zlepšenie.

[Ondrej 'SanTiago' Zajicek]

Zvlastni, ja zas podobne dobre vysledky jsem videl na kazdem hardware, kde jsem to testoval. At uz Asus Eee s Atomem, Deska s VIA C3 ci jine beznejsi platformy. Samozrejme vse s EHCI USB radicem. Abys provedl smysluplne srovnani, musis testovat srovnatelne - tedy v obou pripadech HDD se stejnym FS, jednou pripojeny pres PATA/SATA a po druhe pres USB. Jinak by se treba mohlo ukazat, ze problem treba vubec neni v USB, ale treba ve spatne implementaci FATky kombinaci s chovanim flash pameti pri zapisu.

[Semo]

Nic take nepozorujem. Niekde na okolo jadra 2.6.29-2.6.31 sa sekalo prehravanie hudby, hoci malo najnizsie nice, stacilo troska nieco robit na desktope. Ale uz v dalsej verzii jadra to bolo ok.

[otasomil]

To je zajimave. Live distribuce bezici kompletne z RAMky timto problemem netpely.

[Luboš Doležel (Doli)]

To je fakt. Vinu vidím i na I/O schedulerech, které všechny svorně naprosto nefungují, jak by měly. Pokud dělá jeden proces hodně I/O, celý systém je mimo provoz.

[J. M.]

Co se týče I/O schedulerů, pamatuji si, že jsem kdysi ten výchozí CFQ (který byl zaveden jako výchozí právě v jádře 2.6.18, a od té doby se to seká jak prase) nahradil původním anticipatory schedulerem (as, který byl výchozí od verze 2.6.0, a pak od verze 2.6.18 v jádře zůstával už jen jako volitelný), a veškeré problémy s interaktivitou při diskové zátěži zmizely. Výkon byl skoro stejně dobrý jako kdysi, ve starých jádrech 2.6. Potom v jádře 2.6.33 udělali tu pokrokovou změnu, že ten volitelný as scheduler z jádra úplně vyhodili, protože je starý, překonaný a k ničemu, když máme nový skvělý CFQ, který je už léta jako výchozí... Takže od té doby už není jiná možnost a zase se to seká jak prase.

[stativ]

Zkoušel jsi deadline? Svého času, když jsem ho používal, tak mi přišel lepší než anticipatory.

[J. M.]

Zkoušel. Vlastně zrovna teď na něm jedu. Přijde mi tak někde mezi as (přijatelné) a CFQ (katastrofa). Ale těžko říct. Mám dojem, že se to i mezi verzemi jádra mění.

[Matlák]

+1 používám staré játro, kvůli truecryptu, který se také od .24 pěkně zpomalil... no a AS používám samozřejmě taky, a naprosto žádné problémy s interaktivitou nemám

[m1c4a1]

Asi jsem šťastnej člověk, ale i když jsem všechny 3 schedulery zkusil, žádný rozdíl jsem při běžné práci nezpozoroval.

[Luboš Doležel (Doli)]

Uf, někdy mám dojem, že z řad vývojářů jádra zdravý rozum vymizel.

[xm]

Problém se u mě projevuje se všemi schedulery - CFQ, anticipatory i deadline (testováno na vícero strojích různých konfigurací v delším časovém období). Pouze u CFQ to občas bylo viditelnější, ale to v posledních verzích jádra myslím opravili. Nějaký vliv na to má třeba i NCQ u SATA, ale opět to není příčinou. Dále třeba nastavení dirty_ratio a dirty_background_ratio, ale opět je to jen malý vliv.

Scheduler na vině není, jde o mnohem hlubší problém linuxového jádra (něco s tím jak 2.6 jádro pracuje s page-cache, alespoň k tomu se dobrali v nějaké staré diskuzi co jsem četl). Jde o dlouhodobý problém, jen se z nějakých podivných důvodů u některých šťastlivců neprojevuje. Jinde je ale viditelný doslova drasticky.

Viz třeba mega-dlouhá diskuze na rootu I/O disku mi zabíjí desktop, která začala už déle jak před rokem, ale skutečného řešení příčiny se v ní stejně nikdo nedobral.

[xm]

Ještě pro doplnění další dvě mega-dlouhé diskuze zaobírající se tímto problémem:

Heavy Disk I/O harms desktop responsiveness (reportováno už v roce 2007)

Large I/O operations result in poor interactive performance and high iowait times (reportováno koncem roku 2008)

[otasomil]

Dnes je tolik RAM a tak by bylo skvely pri bootu cely system nahrat do pameti.

Urcite by to prospelo i windows ci jinym platformam. Neni nic horsiho, kdyz system kvuliva nekolikabajtovymu souboru musi hrabnout na disk.

[Heron]

SSD

[Ondrej 'SanTiago' Zajicek]

Vinu vidím i na I/O schedulerech, které všechny svorně naprosto nefungují, jak by měly.

A zkoumal jsi to, nebo jen povrchne usuzujes na zaklade "IO scheduler ma schedulovat a scheduluje se to spatne -> na vine je IO scheduler"? Ono take je dost mozne, ze na vine je obecny memory management.

[xm]

Ono take je dost mozne, ze na vine je obecny memory management.

Bingo! Alespoň všechny indicie tomu nasvědčují.

[Mrkva]

No, patchnul jsem to (doufám, že dobře - musel jsem to trochu upravit pro aktuální jádro). Při té příležitosti změnil IO plánovač za Deadline. A rozhodně mi přijde, že se situace zlepšila... Pravda, pořád se občas zasekne přehrávaná hudba při kompilaci nebo prási s portage, ale už to není tak strašné.

[SAM:]

Tak testuji gentoo-sources 2.6.35 + io stalling patch. Mám situaci, kdy mi ve VMWare běží dva virtuální stroje. Kopírování ISO image z virtuálu na hosta dokázalo komp spolehlivě zatuhnout po dobu kopírování. Průměrně se kopírovalo rychlostí tak 15-20 MB/s. Po nasazení patche komp netuhne a kopírování jede cca 40 MB/s.

[Jendа]

To vypadá moc dobře… Doufám, že to bude v příští vanile.

[frEon]

netuhne? tak to je dobre, asi to vyzkousim az to backportuji do 2.6.32

[krab1k]

Tak to by byla asi pro mě a pro linux asi nejlepší zpráva za hodně dlouho. Už se těším.