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

25. 11. 2013 | Luboš Doležel | Jaderné noviny | 11327×

Aktuální verze jádra: 3.12. Citáty týdne: Mel Gorman, Ingo Molnar, Steven Rostedt. Podpora atomických blokových I/O operací. Zákeřný problém se zamrzajícími flashkami: Podstata problému; Obezličky a opravy.

Obsah

• Aktuální verze jádra: 3.12
• Citáty týdne: Mel Gorman, Ingo Molnar, Steven Rostedt
• Podpora atomických blokových I/O operací
• Zákeřný problém se zamrzajícími flashkami
  • Podstata problému
  • Obezličky a opravy

Aktuální verze jádra: 3.12

Vyšlo jádro verze 3.12, a to 3. listopadu. Váhal jsem, jestli udělat rc8, nebo rovnou konečnou verzi, ale jelikož hlavním důvodem, proč *nedělat* konečnou verzi nebyl ani stav kódu, nýbrž prostě skutečnost, že budu během příštího týdne cestovat s velmi špatným připojením k Internetu, jsem už nechtěl vydání dále odkládat.

Mezi hlavní novinky v tomto vydání jsou vylepšení v kódu pro dynamický tik, podpůrná infrastruktura pro vykreslovací uzly [render node] v DRM, automatické rozvrhování velikosti TSO a plánovač FQ v síťové vrstvě, podpora uživatelských jmenných prostorů v XFS, vícevlákenný RAID5 v subsystému MD, offline deduplikace dat v systému souborů Btrfs a ještě více. Více se dozvíte na KernelNewbies.

Linus v oznámení upozornil na několik dalších věcí. Jednou z nich je, že začleňovací okno 3.13 tento týden ještě nezačne. Začíná navíc přemýšlet o verzi 4.0 a nadhodil, že by 4.0 bylo vydání, kde by byly jen opravy, i když má pochyby, že by to vyšlo. Ale nedá mi to. Třeba by to vyšlo a já jen zbytečně nedůvěřuji ostatním. Kdyby se nám podařilo upozornit dostatek lidí (i firem/manažerů), že jediné patche, které budou přijaty, jsou opravy chyb, třeba by se nám to mohlo povést.

Citáty týdne: Mel Gorman, Ingo Molnar, Steven Rostedt

Myslím si, že jako komunita stále spoléháme na to, že enterprise distribuce a jejich partneři udělají důsledné testování všech velkých vydání. Není to ideální situace, ale nikdy nebudeme moci vyhradit dostatek fyzických, finančních nebo lidských prostředků na to, abychom to udělali celé sami.

-- Mel Gorman

Obvykle to nejsou vývojáři, kdo má rozhodující dopad na stabilitu subsystému, nýbrž správci, a hlavním způsobem, jak zajistit stabilitu kromě opatrnosti při začleňování patche, je, pamatovat si/sledovat všechny problémy a nezačleňovat od stejného vývojáře žádné novinky, dokud neopraví chyby, co nadělal.

-- Ingo Molnar

Váhám, jestli by se to mělo pojmenovat jako kernel/locks, protože to znamená míň psaní, kratší názvy cest a když si to dáte do bagety, tak to dobře chutná.

-- Steven Rostedt

Podpora atomických blokových I/O operací

Některá novější uložná zařízení mají schopnost dělat atomické I/O operace. Atomická operace buď celá uspěje, nebo selže; pokud se má zapisovat více bloků, tak se buď zapíšou všechny, nebo žádné. Tato funkce má potenciál značně zlepšit žití ve vyšších vrstvách, ale jádro nemá aktuálně žádný způsob, jak ji podporovat.

Sada patchů pro atomické I/O od Chrise Masona se tento stav pokouší napravit. Umožňuje soubor otevřít s příznaky O_ATOMIC a O_DIRECT (je podporované jen přímé I/O) pro získání atomické funkčnosti. Od té doby bude každé volání write() provedeno atomicky, pokud to hardware podporuje. Tuto funkci je proto snadné používat z uživatelského prostoru.

V rámci jádra je pro blokové ovladače k dispozici nová funkce:

void blk_queue_set_atomic_write(struct request_queue *q,
    				    unsigned int segments);

Tato funkce blokové vrstvě řekne, že zařízení za danou frontou požadavků dokáže provádět atomické operace až do daného počtu segmentů. Poté mohou I/O požadavky přicházet s příznakem REQ_ATOMIC, který označuje žádost o atomické provedení. Bloková vrstva se postará o to, že maximální počet segmentů nebude překročen.

Tato funkčnost může najít řadu využití. Systém souborů s žurnálem například může zapisovat žurnál a blok s commitem současně a bude vědět, že zapsaný blok s commitem bude viditelný jen tehdy, pokud se podařilo zapsat i vše ostatní. Chris ale říká, že prvním cílem je MySQL:

O_ATOMIC | O_DIRECT umožňuje mysql a podobným vypnout dvojité bufferování. Toto snižuje jejich I/O na polovinu, díky čemuž pak jsou zhruba 2× přátelštější k flash úložištím.

Sada patchů (která nepřidává žádnou podporu do jakýchkoliv ovladačů v blokové vrstvě) je docela malý a jednoduchý, takže je docela velká šance, že bude ve velmi brzké budoucnosti začleněn.

Zákeřný problém se zamrzajícími flashkami

Artem S. Tashkinov nedávno narazil na problém, kteří jistě někteří čtenáři znají. Připojte pomalé úložné zařízení (USB flasku nebo třeba nějaký přehrávač) do linuxového stroje a zapište na něj hodně dat. Celý systém se nakonec zasekne, možná i na celé minuty. Nakonec se to zase rozjede, ale znechucený uživatel možná mezitím odešel na pivo; než bude systém zase použitelný, tak už uživatel nemusí mít o danou operaci ani zájem.

Tentokrát ale Artem vypozoroval něco zajímavého: systém se zasekne při běhu na 64bitovém jádře, ale nic takového se mu na stejném hardwaru neděje na 32bitovém jádře. Člověk by čekal, že subsystém blokového I/O bude od detailů jako délka slova procesoru izolován, ale v tomto případě by se jeden divil.

Podstata problému

Linus rychle pochopil, co se děje. Jde o problém srovnání rychlosti, jakou proces v paměti vytváří špinavé [dirty] stránky, a rychlosti, jakou je možné tuto paměť zapisovat na úložné zařízení. Pokud je procesu umožněno znečistit velký objem paměti, pak bude jádro muset zapisovat blok dat, jehož zápis potrvá minuty. A tato data ucpou I/O fronty a množná i opozdí další operace. Jakmile někdo zavolá sync(), tak se vše zastaví, dokud není zapsán veškerý obsah ve frontě. Jde o ekvivalent problému bufferbloat, jen v úložných zařízeních.

Vývojáři zodpovědní za subsystémy pro správu paměti a blokové I/O o tomto problému vědí. Aby bylo možné problému předejít, tak vytvořili sadu nastavitelných hodnot pod /proc/sys/vm, pomocí kterých se dá řídit, co se má dít, pokud proces vytváří mnoho špinavých stránek. Jde o:

• dirty_background_ratio určuje procento paměti; pokud je alespoň tolik procent špinavých, tak začně jádro zapisovat tyto stránky na disk. Proto pokud má systém 1000 stránek paměti a dirty_background_ratio má hodnotu 10 % (výchozí hodnota), tak zpětný zápis započne po ušpinění 100 stránek.
• dirty_ratio určuje procento, při kterém proces, který stránky znečišťuje, bude muset čekat na zpětný zápis. Pokud je toto nastaveno na 20 % (opět výchozí hodnota) na 1000stránkovém systému, tak bude proces znečišťující stránky muset čekat po ušpinění 200. stránky. Tento mechanismus nakonec zpomalí špinění stránek, zatímco se systém snaží věci dohnat.
• dirty_background_bytes funguje jako dirty_background_ratio, akorát je zde limit stanoven v bajtech.
• dirty_bytes je ekvivalentem dirty_ratio, akorát je stanoven v bajtech.

Nastavení těchto limitů na nízké hodnoty může také mít dopad na výkon: dočasné soubory, které budou hned odstraněny, budou zapisovány na úložiště a drobné I/O operace mohou vést k nižší propustnosti I/O a horšímu umístění na disku. Nastavení příliš vysokých limitů zase může vést k problémům z přílišného bufferování, jako je popisováno výše.

Pozorný čtenář by se mohl ptát: co se stane, když správce nastavít dirty_ratio i dirty_bytes, hlavně když hodnoty nesouhlasí? Funguje to tak, že platí buď limit v procentech, nebo v bajtech, ale ne obojí. Platí zkrátka ten, který byl nastaven jako poslední; nastavení dirty_background_bytes na nějakou hodnotu způsobí přenastavení dirty_background_ratio na nulu.

Jsou tu další dva detaily, které jsou klíčové k pochopení chování, jaké popisuje Artem: 1) ve výchozím nastavení se používají procenta a 2) na 32bitových systémech se poměr aplikuje podle objemu low memory (nízké oblasti paměti) – tedy paměti přímo adresovatelné jádrem, nikoliv podle celkového objemu paměti. Na snad všech 32bitových systémech do této nízké oblasti spadá jen prvních ~900 MB paměti. Proto jakýkoliv nový systém s rozumným objemem paměti bude mít na 64bitovém jádře jiné hodnoty dirty_background_ratio a dirty_ratio než na 32bitovém. Na Artemově systému s 16 GB RAM bude 64bitový limit dirty_ratio odpovídat 3,2 GB; na 32bitovém jádře to bude přibližně 180 MB.

Tento (obří) rozdíl mezi těmito limity se hned projeví při zápisu na pomalé úložné zařízení. Nižší limit neumožní nahromadění zdaleka tak velkého objemu dat, než začne brzdění procesu, který zapisuje data, což má pro uživatele systému mnohem lepší výsledky (leda by uživatel chtěl naštvaně odejít na pivo).

Obezličky a opravy

Jakmile je podstata problému jasná, tak se může začít mluvit o řešeních. Linus navrhl, že kdokoliv narazí na podobný problém, by mohl problém obejít snížením dirty_background_bytes a dirty_bytes na rozumné hodnoty. Ale obecně panuje shoda, že výchozí hodnoty na 64bitových systémech nedávají na současných systémech moc smysl. Pravdou je, že podle Linuse jsou limity určené pomocí procent obecně přežitkem:

Používání procent pochází z dob, kdy jsme obvykle měli 8-64 *megabajtů* paměti. Takže pokud jste měli 8MB stroj, tak jste nechtěli mít více než 1 MB zabraný špinavými stránkami, ale když jste byli „pan Zbohatlík“ a mohli si dovolit 64 MB, tak jste mohli mít až 8 MB pro špinavé stránky.

Věci se teď mají jinak.

Proto navrhl, že by mohly výchozí hodnoty být změněny na údaje v bajtech; nebo by se limity v procentech vztahovaly jen na první 1 GB paměti.

Samozřejmě by bylo hezčí mít v jádře chytřejší chování. Limit, který se vztahuje na pomalé USB zařízení, nemusí být vhodný pro vysokorychlostní úložné pole. Jádro teď má logiku, pomocí které se snaží odhadnout skutečné rychlosti zpětného zápisu na každém připojeném zařízení; díky tomu by mohlo jít omezovat počet špinavých stránek na základě času, jak dlouho potrvá jejich zápis. Ale jak Mel Gorman upozornil, tento přístup není snadné implementovat.

Andreas Dilger tvrdil, že celá myšlenka shromažďovat data před zahájením I/O už není užitečná. Systém souborů Lustre bude spouštět I/O při cca. 8 MB dat; myslí si, že podobné pravidlo (aplikované na jednotlivé soubory) by mohlo vyřešit spoustu problémů s minimem složitostí. Dave Chinner ale vnímá situaci jako mnohem složitější; takové pravidlo by při řadě zátěží nefungovalo.

Dave místo toho navrhuje, že by se jádro mohlo zaměřit na implementaci dvou základních pravidel: „cachování zpětného zápisu“ (tak vlastně věci fungují teď) a „cachování přímého zápisu [writethrough]“, kde by platily nižší limity a I/O by začalo dříve. Zpětný zápis by se používal pro většinu zátěží, ale writethrough dává smysl u pomalých zařízení nebo při sekvenčním streamování. Klíčové pak je, aby jádro dokázalo rozhodnout, jaká pravidla použít, bez zásahu uživatele. Máme tu nějaké zjevné indikace včetně různých volání fadvise() nebo vysokorychlostního sekvenčního I/O, ale bez pochyb by se musely dořešit všemožné detaily.

Z krátkodobého hlediska ale s nejvyšší pravděpodobností uvidíme relativně jednoduché opravy. Linus zaslal patch omezující procentuální výpočty na první 1 GB paměti. Tento druh opravy by se mohl dostat do verze 3.13; hezčí řešení pochopitelně zaberou více času.

       

Komentáře

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