Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj (diskuse)

[Honza Jaroš]

Doporučuji nahradit v textu <tt>O_DIRECT</a> za <tt>O_DIRECT</tt>...

[petr_p]

Long live XML.

[Marián Kyral]

No je to takové... ...nezvyklé

[Conscript89]

XML by se ani nezobrazilo, mas spis na mysli SGML, ne?

[xkucf03]

+1 při použití XML by se chyba odhalila hned při vkládání článku

[Jendа]

HTML jde taky validovat.

[xkucf03]

Akorát je to o dost složitější a nestačí na to běžný XML parser, který je snad všude.

[D.A.Tiger]

Myslim ze u XML takove veci neprojdou uz pri parsovani. Zatimco HTML tise lecktera "zverstva a preklepy" toleruje, nebo alespon ignoruje.

[Václav HFechs Švirga]

Kdyby byly webove stranky v XML (nebo validne parsovanem XHTML - obvykle se XHTML parsuje s mime typem HTML, tedy vubec ne jako XML), tak si taky musis pockat, nez se cela stranka dotahne. Na mobilu s gprs super... A kdyby externi poskytoval obsahu (treba dodavatel reklamy) udelal jedinou chybku, neuvidis nic. Taky super... Nic neni cernobile a taky mozna proto mame HTML5 a ne XHTML2 .

[petr_p]

musis pockat, nez se cela stranka dotahne.

FUD. Co jsou asi SAX parsery? Zpracovávat můžeš průběžně. Jen po nalezení chyby musíš ohlásit chybu a veškeré rozdělané operace zrušit.

A kdyby externi poskytoval obsahu (treba dodavatel reklamy) udelal jedinou chybku, neuvidis nic.

FUD. XHTML zcela rozumně nepodporuje innerHTML, tedy úpravy znak po znaku. Vždy je nutné pracovat přes DOM, takže nikdy nemůže vzniknout chybně utvořený dokument.

[xkucf03]

+1 U XML není problém zpracovávat ani „nekonečné“ soubory – na vstupu máš XML, které nemusí nikdy skončit, a na výstupu máš SAX události, které se nějak zpracovávají.

[Miloslav Ponkrác]

Pokud nějaký text nebo atribut nemá „nekonečnou“ délku hodnoty.

[xkucf03]

U atributu by to byl problém. Ale text by šel rozsekat na více textových uzlů a posílat je postupně, ne?

[D.A.Tiger]

Dost dobre si nedovedu predstavit, z jakeho praktickeho duvodu bych primo do atributu tagu (notabene u XML), daval hodnotu s "nekonecnou" delkou...

[Luk]

A co třeba něco jako:

<img src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOy..." alt="" />

?

[D.A.Tiger]

No, prave. Sice proti gustu zadnej disputat, ale me prijde jako zhovadilost vkladat rozsahla data do XML primo, kdyz parser muze klidne pradat typ a soubor. Aplikace uz bude urcite vedet co s tim....

[xkucf03]

BTW: u binárních formátů zase často bývá problém, že délka atributu se popisuje určitým pevně daným datovým typem – a ten má svoje limity, takže často ani tam nemůžou být nekonečné atributy nebo nekonečně dlouhé zprávy.

[trekker.dk]

Když jsme u toho, tak třetí citát nemá správný styl.

[lertimir]

Zpomalení není jen na 64 bitovém jádře, ale i na 32 bitovém jádře. Záleží na tom s jak pomalým zařízením se pracuje. Nedávno jsem potřeboval pracovat z 32 bitového systému (notebook pod 4GB paměti proto 32bit) s datovým úložištěm. Připojil jsem jej standardně přes NFS, ale byl jsem na pomalé wifi (efektivní rychlost přenosu cca 1-1,5MB/s) a přenášel jsem větší objem několik desítek souborů s celkovým objemem cca 3GB. Očekával jsem, že to spustím, data se budou přenášet, a já mezitím budu pracovat na něčem jiném. Bohužel celý systém se stal v podstatě nepoužitelný do ukončení přenosu.

[marek_hb]

podobná zkušenost - trochu nepříjemné třeba v případě:

ahoj, nahraj mi ty fotky na flešku - jo a koukni na maila, něco jsem ti posílal a dělej - spěcháme - ty vole, co to máš za počítač???? dyk to nefunguje ....

[R]

Podla mna je tam vacsi problem: preco zapis na jedno zariadenie zablokuje cely system?

[tap]

Podla mna je tam vacsi problem: preco zapis na jedno zariadenie zablokuje cely system?

vid. clanok: A tato data ucpou I/O fronty a množná i opozdí další operace

[R]

I/O fronty nie su pre jednotlive zariadenia oddelene?

[Luboš Doležel (Doli)]

Přesně to mě taky napadlo.

[tap]

Neviem, mozno to bude suvisiet so semantikou sync(2) Viem si tiez zivo predstavit, ze v realnej aplikacii sice je zapis hlavne na flesku ale je tam aj nejaky minizapis na normalny disk (mozno len nejake metadata). No a sync garantuje ze sa flushne vsetko.

[R]

Tak to moze byt problem. Kazdopadne by sa globalny sync nemal pouzivat, ked nie je nutny - a to nie je takmer nikdy. Priamo v tom manuali je syncfs.

[Luboš Doležel (Doli)]

syncfs() je relativně novinka a je Linux-specific. Správný způsob je podle mě zavolat fsync() na konkrétním souboru a nadřazeném adresáři (pokud byla měněna/vytvářena samotná položka souboru).

[Jendа]

Viem si tiez zivo predstavit, ze v realnej aplikacii sice je zapis hlavne na flesku ale je tam aj nejaky minizapis na normalny disk (mozno len nejake metadata).

Ale mně cp zapisující na flashku klidně blokne Firefox, který s flashkou nemá nic společného.

No a sync garantuje ze sa flushne vsetko.

I tak bych čekal, že to bude flushovat na různá zařízení paralelně.

Hm, ale kdyby fakt rostla jednotná fronta, tak by to asi šlo - další procesy se ani nedostanou do fronty, ale rovnou freeznou.

[lertimir]

Navíc, nevíce efektivní by mi připadalo mít jednotlivé fronty pro jednotlivá zařízení oddělené a limity definovat ne procentuálním poměrem nebo absolutní hodnotou bufferu, ale časem. Čas by znamenal dobu, kterou bude mít buffer data na maximální rychlosti zařízení. Přece jen mé SSD SATA3 v notebooku s tabulkovou rychlostí cca 500MB/s a NFS disk připojený přes IEEE 802.11g s efektivní rychlostí max 3MB/s potřebují zcela jinou velikost bufferů. Mít specifikované velikosti bufferů časem, který má buffer zachytit plnou rychlost zařízení by všechna zařízení mohla mít ekvivalentní podmínky, třeba tak, že buffer zachytí 0,5 s provozu (a systém by si mohl rychlost průběžně měřit), by se u té wifi bylo v bufferu cca 1,5 MB a po půl vteřinách by byla možná nějaká akce, i když I/O buffer blokne systém.

[Michal Kubeček]

(Podotýkám, že nejsem ani zdaleka odborník na blokovou vrstvu, takže to, co píšu, je potřeba brát s rezervou.)

Jeden potenciální problém vidím v tom, že tady není řeč o frontě requestů konkrétního fyzického zařízení, ale o page cache. Na téhle úrovni nemusí být na první pohled jasné, na jakém fyzickém zařízení určitá stránka nakonec skončí (a jestli vůbec na nějakém).

Mimochodem, i ta myšlenka zohlednit rychlost zařízení, je v článku zmíněna, ale jak už to bývá, ďábel se skrývá v detailech a těch podle odkazovaného mailu zbývá dořešit ještě docela dost. Některé jsou navíc způsobeny absurdním chováním aplikací, s čímž se dá v jádře dělat nanejvýš to, že ho vezmete na vědomí a budete s ním počítat. Navíc se nelze příliš zaměřit jen na jeden use case, aby nedošlo k tomu, že řešení problému "zápis na flash disk mi zasekává KDE" způsobí výraznou výkonnostní regresi třeba u vytížených fileserverů s velkým počtem rychlých disků

[lertimir]

Podle mne je jedna z podstatných otázek ta, jestli má být ve všech systémech stejné řešení všech jaderných subsystémů. Můj názor je ten, že servery a pracovní stanice řeší jinou optimalizační úlohu. Server řeší úlohu maximalizace výkonu a v jistém smyslu i výběr komponent odpovídá něčemu, co bych nazval "sladění", pracovní stanice řeší úlohu maximalizace efektivní práce uživatele, což znamená, že za všech okolností by uživatel měl dostat co nejkratší čas reakce systému na akce, které dělá. Tenhle můj názor, že na stanici je prioritní uživatel, jsem se v jiném kontextu pokusil uvést i tady a jak je z následné diskuse vidět, někteří si myslí že optimalizace pro stroj je důležitější než optimalizace pro člověka.

Moc netuším, jestli je možné poslat informaci o tom, které okno je nahoře, které okno má fokus, která okna jsou částečně viditelná a která nejsou vůbec vidět, a na základě této informace mít třeba jinak optimalizovaný scheduler a/nebo I/O subsystém. Např. pokud v Krusaderu spustím nějaké kopírování/přesun a zvolím "zařadit do fronty" tak dávám najevo, že ho v podstatě chci mít v pozadí, nezajímá mne rychlost přenosu (v tom smyslu, že sice očekávám, že přenos bude maximální rychlostí, ale tak, že mne v žádném případě kopírování nemá zdržovat, a když budu něco dělat s čímž koliduje ať stojí.) Myslím si, že díky v podstatě obrovskému výkonu stolních počítačů, ta reakce desktop systému není špatná i v případě použití fair shedulerů a I/O subsystémů, které neprioritizují operace a nějak se to do systému férově naskládá. Až jak vidět na ty případy, kdy jeden subsystém je výrazně horší kvality. (což by se v případě serveru nestalo, protože tam si ten HW vybírám a "slaďuji".)

Pokud se bude linux v nějaké časovém horizontu více rozšiřovat na desktopu, tak otázka optimalizace systému na "user response" bude závažnější.

[Jakub Lucký]

Paradoxně zjišťuju, že až na onu nepříjemnost se zápisy do NFS/na blbou flešku je pro mne Linux nejrychleji reagující systém (a pokud není, tak jsem schopen to ovlivnit)

[xkucf03]

+1 akorát už mi to nepřijde tak paradoxní jako dřív. Občas jsem byl s odezvou desktopu na GNU/Linuxu trochu nespokojený, ale vyléčilo mne z toho, když jsem si občas sedl k nějakým cizím Windows.

[lertimir]

Nepopírám, že reaguje celkem dobře, ale já mívám ještě další situace, kdy bych jinou prioritizaci velmi uvítal.

1. Masívní diskové operace. Nestává se často, ale občas potřebuji přeoganizovat archivy,(fotky a filmy) mezi svými disky. Přesouvání/kopírování 1-2TB. A v té chvíli pokud si nedám pozor, jak operace naskládat krusaderu do front, se systém výrazně zpomaluje. Vím, že mohu ty procesy najít a měnit jim nice, občas to dělám, ale ve chvíli, kdy jsou to desítky, stovky jednotlivých příkazů není to až tak handy.
2. Operace s fotkama a neochota autorů foto programů mít fotky přednačtené. viz odkaz v předchozím příspěvku.
3. Náročnější matematické výpočty, jsou situace kdy výpočty třeba v R ku nebo simulace běží půl hodiny i déle a v té době reakce jsou horší. podobně kódování videí.

V naprosté většině jiných situaci je desktop s výraznou rezervou výkonu a reakce jsou dost rychlé. Se SSD zvláště.

[Jakub Lucký]

1 a 2 neznám, na 3 nice 19 nepomůže? Popř. výměna scheduleru?

[lertimir]

Na 3 nice pomůže, ale pointa není v tom, že to nejde ručně vyřešit. To co jsem chtěl zdůraznit, že už to, že takovou situaci řeším ručním zásahem, vnímám jako špatně. V serveru jsou v podstatě všechny procesy rovnoprávné a mají právo o férový přístup na zdroje (a pokud ne tak to přes nice se vyřeší.) V desktopu to tak principielně není. Důležitější a prioritnější by měl být ten proces s nímž uživatel pracuje a ty ostatní by měly spravovány, tak aby tento hlavní nerušily.

Jako příklad, dělám nějaké operace s videem nebo s fotkami nebo organizace disků. Provedu náhledy a spustím dávkové zpracování aby se vše co jsem chtěl udělat fakticky provedlo. Pak přepnu na editor nebo inkscape nebo poštu a současně přitom čtu nějaké grafické PDF. To co bych rád, aby běžící operace mne nezdržovaly, jestli se tím jejich celkový běh protáhne třeba z 30 na 35 minut, je mi v podstatě jedno, ale bude mi vadit, když přeroluji PDF a budu čekat 4 vteřiny než se PDF vykreslí, protože ten background potřebuje disk nebo procesor. A to, že je proces bez interakce s uživatelem systém ví. Třeba tak, že okno nemá fokus, nebo je minimalizované, nebo tak, že "je vespod" a není tím pádem vidět.

A také netvrdím, že ostatní systémy jsou na tom lépe. Naopak, způsobů, jak se mi Win kously nebo měli strašnou reakci, bylo mnoho. Ale to, že to jinde dělají ještě hůř není argument, abychom něco nezkusili i zlepšit. A také beru, že někde mohu mít chybu v úvaze a idea je nefunkční, ale zatím si myslím, že jiný přistup k prioritě by desktopy potřebovaly.

[pavlix]

To co jsem chtěl zdůraznit, že už to, že takovou situaci řeším ručním zásahem, vnímám jako špatně.

Taky to vidím jako hlavní obsah tvého předchozího sdělení.

[petr_p]

Provedu náhledy a spustím dávkové zpracování aby se vše co jsem chtěl udělat fakticky provedlo.

Tady předně měl uvažovat autor programu a při dávkovém zpracování zvýšit nice.

Třeba tak, že okno nemá fokus, nebo je minimalizované, nebo tak, že "je vespod" a není tím pádem vidět.

Je triviální zjistit XID aktivního okna, méně spolehlivé z _NET_WM_PID property získat PID a procesu zvýšit prioritu.

Trochu narážíme, že snižovat nice může je proces s CAP_SYS_NICE, což tradičně běžný uživatel není.

Kdysi se dělaly pokusy s řídicími skupinami podle uživatelských relací. Kam to došlo, netuším.

[pavlix]

Tady předně měl uvažovat autor programu a při dávkovém zpracování zvýšit nice.

Taková reakce je dost mimo kontext jak toho, co lertemir psal, tak toho, že máme osmdesátá léta daleko za sebou.

Kdysi se dělaly pokusy s řídicími skupinami podle uživatelských relací. Kam to došlo, netuším.

Lennart už se na to docela chystá, pokud vím :).

[Lol Phirae]

Lennart už se na to docela chystá, pokud vím :).

OMG.

[Jakub Lucký]

Lennart už se na to docela chystá, pokud vím :).

* Jakub Lucký shoots himself in the head

[Conscript89]

Snad to bude jenom v Gnome :)

[pavlix]

Všude, kde se použijí systemd user sessions.

[Love_Dali]

Přesně to se mi už nějakou dobu děje a negeneralizoval bych to pouze na "pomalé flashky".. Poradí mi někdo, jak si opatchovat jádro tímhle patchem? Už jsem podobný věci neřešil nějakou dobou. Arch kernel 3.12-1 Tack so mycket ;)

[Michal Kubeček]

Proč byste to dělal, když stačí nastavit jeden parametr?

[Love_Dali]

done & working ;)

[marek_hb]

takže stačí třeba něco takového?:

echo 5 > /proc/sys/vm/dirty_background_ratio

??

[Michal Kubeček]

Záleží na tom, kolik má ten systém paměti. Jak je vysvětleno v článku, problém je právě v tom, že dnes není až tak neobvyklé mít i v desktopu 16 GB a více RAM, takže těch defaultních "pár procent" může být příliš mnoho. (Mimochodem, trochu mi to připomíná defaultních 5 procent rezervovaných bloků na ext2/3/4.) Takže bych spíš doporučil nastavit rovnou dirty_background_bytes.

[marek_hb]

tak potvrzeno na debian sid E6600, 4 GB RAM, nějaký SSD od kingstona

uname -a

Linux debian-desktop 3.12-trunk-amd64 #1 SMP Debian 3.12-1~exp1 (2013-11-17) x86_64 GNU/Linux

ale i při:

cat /proc/sys/vm/dirty_background_ratio

5

co je špatně? při kopírování ze síťového disku na pomalou kartu přes čtečku se systém sekal a ne málo

[Václav HFechs Švirga]

Možná v tom, že nemáš zkusit nastavovat, jak píše Kubeček, ratio, ale bytes. A to na nějakou nízkou hodnotu, zkus 16 MB nebo tak něco a pak poreferuj, taky mě to zajímá

[Kvakor]

Přesně, např. na vanilla jádře 3.12.1 je defaultně /proc/sys/vm/dirty_background_bytes nastavené na nulu a /proc/sys/vm/dirty_background_ratio na deset procent, tudíž se berou procena a ne byty.

[marek_hb]

vyzkoušeno - pořadí příkazů:

echo 0 /proc/sys/vm/dirty_background_ratio

echo 16777216 /proc/sys/vm/dirty_background_bytes

kousání pokračuje dál - dělám něco špatně?

[Michal Kubeček]

(Budu předpokládat, že ta většítka jste vynechal a ve skutečnosti je tam máte.)

Pokud nastavíte na nižší hodnotu pouze dirty_background_bytes, ale ponecháte defaultní dirty_ratio=20, znamená to (při 4 GB paměti), že writeback sice začne už při 16 MB dirty pages, ale protože writeback bude mnohem pomalejší než tempo, kterým zapisující proces "špiní" stránky, stejně mu ve výsledku dovolíte vyrobit až zhruba 800 MB dirty pages, než začne čekat (což při zápisu většího souboru hravě zvládne).

Chcete-li vyzkoušet, jak se to bude (defaultně) chovat s Linusovým patchem, potřebujete nastavit dirty_background_bytes zhruba na 100 MB a dirty_bytes asi na 200 MB (tj. 10% resp. 20% z 1 GB). Případně můžete experimentovat i s hodnotami nižšími, ale opět je potřeba nastavovat obě.

[Mti.]

ehm... mozna neco prehlizim, mozna se pletu do debaty pro dospele... ale v okamziku, kdy sem do dirty_background_bytes zapsal cokoliv, ratio se prepsalo na 0. (puvodne bytes bylo 0 a ratio 5) Po zapisu do ratio se nuluje bytes Tj. neumim "najednou" nastavit oboji. Co mi unika?

[Michal Kubeček]

Že jsem nepsal, že má nastavovat dirty_background_bytes a dirty_background_ratio, ale dirty_background_bytes a dirty_bytes.

Začínám mít pocit, že polovina účastníků této větve diskuse ten článek vlastně nečetla…

[Mti.]

Nevim jestli su polovina, ale toto sem prehlidl a moc se omlouvam.

[marek_hb]

já jsem asi ta druhá polovina - většítka jsem tam měl, ale tupě jsem nasatavoval ratio - ráno zkusím a poreferuju :(

[marek_hb]

takže postup:

root@debian-desktop:/home/marek# echo 0 > /proc/sys/vm/dirty_background_ratio

root@debian-desktop:/home/marek# echo 33554432 > /proc/sys/vm/dirty_background_bytes

root@debian-desktop:/home/marek# echo 66554432 > /proc/sys/vm/dirty_bytes

asi zabral - k cukání nedochází, jen občas k mírnému zpomalení

[Love_Dali]

Chlapi, možná jsem naprostý idiot, ale nacpal jsem do grub cfg k paramtetrům kernelu vm_highmem_is_dirtyable a všechno, zatím jede ok..

[trubicoid2]

tak to jsi sam aplikoval ten Linusuv patch? jinak ve vanilkovym 3.13.5 to nevidim, asi teda placebo efekt

[SGF]

Moje zkušenost je taková, že se to stává pouze pokud běží proces nautilus, tedy buď jeho otevřené okno nebo třeba spravuje plochu. Pokud kopíruju přes krusader v Gnome, kde nemám zapnutou správu plochu nautilem, jede to bez problému a nic se neseká. Když otevřu okno nautila, zasekne se to a dokud se soubor nedokopíruje, je to seknutý, a to i když nekopíruje nautilus, ale krusader. Prostě stačí, že ten proces běží.

[lertimir]

Tohle bylo kompletně v KDE. Kopiroval to Dolphin. Nicméně bloknutí systému při zápisu na flashku se mi stalo i v Krusaderu. (tam to byl 64 bitový systém.) Ale snad se tím konečně někdo bude zabývat.

[Conscript89]

Hehe, ja musim rict, ze se mi to deje celkem bezne pri dd s blocksize 1M. Kopirovani z SSD na USB3 flashku 4GB image (8GB ram).

[R]

Pri dd pouzi oflag=direct.

[filbar]

Já mám podobný problém, ale jenom ve spojení s WWW prohlížečem Firefox, když přes něj něco většího stahuju tak mi to žeře skoro 100% CPU :O

[Marián Kyral]

nadhodil, že by 4.0 bylo vydání, kde by byly jen opravy

To jako, že 3.1 až 3.12 byly beta? A 4.1 bude zase beta pro 5.0?

[Michal Kubeček]

Ne, prostě jen navrhl, že by se v jednom cyklu nepřidávaly žádné featury, ale jenom bugfixy. V následné diskusi ale tahle myšlenka moc velkou podporu neměla.

[Nikola Ciprich]

v podstatě by jen 4.X vyhradil pro -stable větev, jako je teď např. 3.10. Takže víceméně nic zas tak nového..

[Michal Kubeček]

Ne. Tohle by se týkalo jen a pouze verze 4.0, ne celé řady. Ale jak už jsem psal, ohlasy byly stejně většinou negativní.

[Nikola Ciprich]

no však to je totéž ne? Vyšla by verze 4.0, a pro tu by pak už vycházely jen a pouze opravy, stejně jako např. pro 3.10. Rozdíl by byl pouze v tom jestli se čísluje 3.x.{1,2,3,4,...} nebo 4.{1,2,3,..}

nicméně jestli se nápad neujal, tak je asi stejně zbytečné to řešit :)

[Michal Kubeček]

Není to totéž. Do 3.10.y stable se (až na výjimky) přijímají pouze vybrané opravy z těch, které se (po vydání 3.10) dostaly do mainline - a zdaleka ne každá oprava se dostane do stable. Oproti tomu by 4.0 byl prostě jen nějaký bod na mainline za poslední 3.x (který by se jinak jmenoval 3.(x+1)). Jediný rozdíl by byl v tom, že by mezi poslední 3.x a 4.0 nebylo žádné merge window.

[D. Toman]

tohle zpomaleni pozoruji uz nekolik let. A vubec ne ve spojitosti s nejakym USB donglem. Po prechodu na 64bit se nam vice serveru zacalo chovat divne - na par sekund (az desitek sekund) obcas 'zatuhly'. K vyvolani jevu staci vyrobit pomoci 'dd' dostatecne velky soubor. Jakmile se zacnou cache sypat na hdd tak je problem. Vsechno to byly/jsou stroje s md raidem (zrcadlo) a lvm. Na strojich s rozumnym HW raidem nastesti problem nevznika (nebo neni tak markantni). Provozovat napr nameserver (bind) na takovem stroji znamenalo, ze obcas odpovedel na dotaz po 10ti sekundach (hned co se dovysypaly cache).

Jsem rad, ze si toho konecne vsimnul nekdo, kdo s tim muze neco udelat...

[Honz]

Artem S. Tashkinov
Já vím, že je to trochu těžké s cizími jmény, ale tenhle borec jmenuje spíš Arťom Taškinov...

[Sten]

Těžko říct, která verze je správná. On sám se takhle podepisuje v LKLM, Linuxu, Gitu, Wine a několika dalších open source projektech.

[Semo]

Chapem spravne, ze po novom uz nebude mozne pouzivat zapisovy diskovy (= block device) buffer vacsi ako 1GB?

Mam 12GB RAM pretoze obcas nieco robim s fotkami/panoramami. Ale drvivu vacsinu casu mam velky kus tejto pamate fakt nevyuzity. Mna celkom tesi chovanie, ze pri presuvani veci po disku sa vsetko udeje pre uzivatela strasne rychlo a system si to potom na pozadi zapisuje na disk. Nie kazdy nastroj ma implementovane vlastne fronty, do ktorych sa len radia poziadavky na operacie a vykonavaju sekvencne.

[xkucf03]

Podle:

Funguje to tak, že platí buď limit v procentech, nebo v bajtech, ale ne obojí. Platí zkrátka ten, který byl nastaven jako poslední;

by mělo jít nastavit velikost v bajtech a tím přebít procenta. Případně nastavit, víc než 100 %, ale to nevím, jestli jde

[Tom K]

ne. chápeš to špatně. pořád si budeš moct ručně nebo třeba ve startovacích skriptech nastavit víc. jen defaultní nastavení, které počítá jádro bude maximálně z jednoho giga.

[Tomáš]

Nevysvětlil by mi někdo proč by nestačilo zvednout velikost front (např: echo 10000 > /sys/block/sda/queue/nr_requests ) proporcionálně k velikosti paměti? Tak aby se fronta nemohla ucpat.

[R]

Pri skutocne pomalom zariadeni ti ziadne taketo veci nepomozu. Predstav si kopirovanie par GB na disk pripojeny cez USB 1.1 alebo NFS namountovany cez pomalu linku.

[Tomáš]

Dokážu si představit, že zápis na pomalé zařízení bude dlouho trvat. Ale nemusí kvůli tomu zatuhnout celý systém. Moje laická představa je, že pokud se fronta zaplní, tak další zápisy do fronty se stanou "blokujícími operacemi", což způsobí "vytuhnutí" systému. A pokud nedojde k tomuto zablokování, tak systém dále žije. To je důvod proč se ptám proč nestačí zvednout velikost front.

Jiná věc je pak ta, že čtení ze zařízení s velkou frontou zápisu může být pomalé protože se o "šířku kanálu" musí dělit. Ale asi by v tomto případě mohlo zafungovat CFQ, které by v mé (laické) představě mělo zaručit všem procesům stejnou šíři kanálu. ( Ve skutečnosti stejnou šíři kanálu ale úměrnou proporcionálně IO prioritě procesu, ale to je už jen drobný detail.)

[Michal Kubeček]

Jak už jsem psal výše, je potřeba rozlišovat mezi frontou requestů na konkrétní fyzické zařízení (tu má každé svou a paralelizace tam funguje) a page cache s limitem počtu dirty pages. Ten problém, o kterém je tu řeč, se týká dirty pages, ne front zařízení.

[ed]

zvacsit velkost fronty je v tomto pripade take inzinierske riesenie. zalozene na predpoklade, ze ak sa za nejaky cas do fronty ulozi tolko poziadaviek, ze sa nestihnu v realnom case vybavit aspon natolko, aby fronta nenarazila na limit. je to cca rovnako efektivne, ako riesit zivotnost latriny pri jej stavbe vykopanim vacsej diery, nez sa povodne planovalo. raz sa aj tak zaplni, len to potrva dlhsie.

druhy problem moze nastat, ak pojde o dve navzajom zavisle operacie, napr. zapis a spatne citanie bloku, neviem ako je toto osefovane v kerneli (predpokladam, ze sa data proste vytiahnu z fronty bez sahania na disk).

[Jiří Svoboda]

Teda, teď jsem docela dlouho dumal, jaký "špatný" zápis máš na mysli. A on je to "spätný". Také jsem nepatřil mezi zastánce diakritiky, ale již jsem prozřel.

[Michal Kubeček]

Lidi, vezměte, prosím, konečně na vědomí, že problém, o kterém se tu bavíme, se netýká front zařízení. Zaplnění fronty requestů USB disku by nijak neblokovalo ten normální.

druhy problem moze nastat, ak pojde o dve navzajom zavisle operacie, napr. zapis a spatne citanie bloku, neviem ako je toto osefovane v kerneli (predpokladam, ze sa data proste vytiahnu z fronty bez sahania na disk).

Ne z fronty, z page cache. O té je tady celou dobu řeč, ne o frontách jednotlivých zařízení.

[Bedňa]

Viď. atomické operácie, že by sa Jardík dočkal podpory v Kernely zapisovania na umierajúci formát CD?