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:55 | Zajímavý software

Společnost Amazon představila Amazon Corretto. Jedná se o fork a distribuci OpenJDK (Open Java Development Kit) s dlouhodobou podporou od Amazonu. Ke stažení je preview verze 8. V plánu je také verze 11. Zdrojové kódy jsou k dispozici na GitHubu. Jedná se o reakci na oznámení společnosti Oracle, že bezplatné aktualizace její Javy nebude možné po lednu 2019 používat komerčně. Název Coretto vychází z Caffè corretto, tj. espressa s alkoholem.

Ladislav Hagara | Komentářů: 0
včera 12:44 | Nová verze

Po roce vývoje od vydání verze 5.2.0 byla vydána verze 5.3.0 svobodného integrovaného vývojového prostředí KDevelop (Wikipedie). Novinkou je analyzátor Clazy. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je i binární balíček s KDevelopem 5.3.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 0
včera 05:55 | Komunita

Ubuntu 19.04 bude mít kódové jméno Disco Dingo. Dle oznámení v diskusním listu ubuntu-devel-announce je ve vývojové verzi Disco Dinga výchozím Pythonem 3 verze 3.7. Perl byl aktualizován na verzi 5.28. OpenSSL 1.0 bude nahrazeno OpenSSL 1.1.1 LTS. Nové instalace Dinga budou mít sloučený /usr. Stane se tak 7 let po sloučení /usr ve Fedoře nebo Arch Linuxu.

Ladislav Hagara | Komentářů: 6
včera 02:22 | IT novinky

V pondělí a úterý proběhl v San Franciscu Chrome Dev Summit 2018. Přehled dění v příspěvcích na Chromium Blogu. Videozáznamy přednášek na YouTube. Představen byl například web pro webové vývojáře web.dev nebo rozšíření webového prohlížeče Chrome s názvem VisBug (YouTube) určené pro webdesignery. Slíbená je podpora Firefoxu.

Ladislav Hagara | Komentářů: 0
13.11. 23:22 | Zajímavý projekt

Byl spuštěn Humble Dystopian Bundle. V balíčku počítačových her jsou také hry běžící na Linuxu: Beholder, Orwell: Keeping an Eye On You, Orwell: Ignorance is Strength a Observer.

Ladislav Hagara | Komentářů: 0
13.11. 22:44 | Zajímavý článek

Jan Klat publikoval na Medium výsledky ankety věnované platům PHP vývojářů. Zúčastnilo se 419 respondentů. Kompletní výsledky na Tabulky Google.

Ladislav Hagara | Komentářů: 1
13.11. 22:22 | Nová verze

Byla vydána nová verze 1.29 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 0
13.11. 11:47 | Pozvánky
Začínáte s automatizací? Chcete se naučit správně používat Ansible? Přijďte na další Prague Containers Meetup 20. listopadu v prostorách Seznamu v Praze na Andělu.
little-drunk-jesus | Komentářů: 0
13.11. 11:47 | Pozvánky
V úterý 20. 11. v Praze proběhne akce Oracle Czech Republic Meetup Group. Od 18.00 si budete moct vyslechnout přednášky NetSuite Developer Toolset a Product Recommendations system at Bronto.
RichardF | Komentářů: 0
13.11. 10:33 | Nová verze

Byly aktualizovány živé instalační obrazy průběžně aktualizované linuxové distribuce Void Linux (Wikipedie). Nejnovější obrazy ve verzi 20181111 jsou k dispozici vedle i686 a x86_64 také pro jednodeskové počítače s ARM: BeagleBone, Cubieboard, Odroid a Raspberry Pi. Void Linux používá balíčkovací systém XBPS (X Binary Package System), LibreSSL a init systém a správce služeb runit. Ke stažení jsou obrazy postavené jak nad glibc, tak nad musl.

Ladislav Hagara | Komentářů: 3
Jak nejčastěji otevíráte dokumenty na počítači?
 (89%)
 (4%)
 (7%)
Celkem 73 hlasů
 Komentářů: 5, poslední včera 21:21
Rozcestník

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

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

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

link

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

link

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í

link

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

link

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

link

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

link

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.

       

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ář

25.11.2013 00:38 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Doporučuji nahradit v textu <tt>O_DIRECT</a> za <tt>O_DIRECT</tt>... :-)
25.11.2013 05:52 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Long live XML.
Marián Kyral avatar 25.11.2013 08:15 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
No je to takové... ...nezvyklé
Conscript89 avatar 25.11.2013 11:44 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
XML by se ani nezobrazilo, mas spis na mysli SGML, ne?
I can only show you the door. You're the one that has to walk through it.
xkucf03 avatar 25.11.2013 15:11 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
+1 při použití XML by se chyba odhalila hned při vkládání článku
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Jendа avatar 25.11.2013 19:19 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
HTML jde taky validovat.
Bojíte se, že když umřete, nebudete nikomu chybět? Pište kód bez komentářů a dělejte nedokumentované změny!
xkucf03 avatar 25.11.2013 20:01 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
D.A.Tiger avatar 26.11.2013 00:24 D.A.Tiger | skóre: 8 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Myslim ze u XML takove veci neprojdou uz pri parsovani. Zatimco HTML tise lecktera "zverstva a preklepy" toleruje, nebo alespon ignoruje.
Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
26.11.2013 01:17 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 ;-).
Baník pyčo!
26.11.2013 06:55 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 26.11.2013 12:29 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

+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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
28.11.2013 23:42 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Pokud nějaký text nebo atribut nemá „nekonečnou“ délku hodnoty.
xkucf03 avatar 28.11.2013 23:47 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
D.A.Tiger avatar 29.11.2013 20:59 D.A.Tiger | skóre: 8 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Dost dobre si nedovedu predstavit, z jakeho praktickeho duvodu bych primo do atributu tagu (notabene u XML), daval hodnotu s "nekonecnou" delkou...
Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
Luk avatar 29.11.2013 22:59 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
A co třeba něco jako:
<img src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOy..." alt=":-)" />
?
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
D.A.Tiger avatar 30.11.2013 00:10 D.A.Tiger | skóre: 8 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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....
Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
xkucf03 avatar 29.11.2013 22:14 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
25.11.2013 08:40 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Když jsme u toho, tak třetí citát nemá správný styl.
Quando omni flunkus moritati
25.11.2013 00:49 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 08:35 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 ....
25.11.2013 08:55 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Podla mna je tam vacsi problem: preco zapis na jedno zariadenie zablokuje cely system?
25.11.2013 09:13 tap
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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
25.11.2013 09:16 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
I/O fronty nie su pre jednotlive zariadenia oddelene?
Luboš Doležel (Doli) avatar 25.11.2013 09:34 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Přesně to mě taky napadlo.
25.11.2013 10:01 tap
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 10:19 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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) avatar 25.11.2013 11:20 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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а avatar 25.11.2013 19:45 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
Bojíte se, že když umřete, nebudete nikomu chybět? Pište kód bez komentářů a dělejte nedokumentované změny!
25.11.2013 22:57 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 23:52 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

(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ů

26.11.2013 11:07 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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ý avatar 26.11.2013 14:23 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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)
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
xkucf03 avatar 26.11.2013 20:57 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
27.11.2013 14:16 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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ý avatar 27.11.2013 15:09 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
1 a 2 neznám, na 3 nice 19 nepomůže? Popř. výměna scheduleru?
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
27.11.2013 16:15 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 27.11.2013 16:46 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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í.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
27.11.2013 17:11 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 27.11.2013 17:25 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 :).
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
27.11.2013 17:57 Lol Phirae | skóre: 23
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Lennart už se na to docela chystá, pokud vím :).
OMG.
Jakub Lucký avatar 28.11.2013 06:46 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Lennart už se na to docela chystá, pokud vím :).

* Jakub Lucký shoots himself in the head
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
Conscript89 avatar 28.11.2013 07:48 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Snad to bude jenom v Gnome :)
I can only show you the door. You're the one that has to walk through it.
pavlix avatar 28.11.2013 11:30 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Všude, kde se použijí systemd user sessions.
Já už tu vlastně ani nejsem. Abclinuxu umřelo.
25.11.2013 10:09 Love_Dali | skóre: 22
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 ;)
25.11.2013 10:20 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Proč byste to dělal, když stačí nastavit jeden parametr?
25.11.2013 11:04 Love_Dali | skóre: 22
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
done & working ;)
25.11.2013 11:57 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
takže stačí třeba něco takového?:

echo 5 > /proc/sys/vm/dirty_background_ratio

??
25.11.2013 13:09 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 14:55 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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
25.11.2013 15:23 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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á
Baník pyčo!
25.11.2013 18:58 Kvakor
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 21:12 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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ě?
25.11.2013 22:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

(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ě.

26.11.2013 15:06 Mti. | skóre: 31 | blog: Mti
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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? :-)
Vidim harddisk mrzuty, jehoz hlava plotny se dotyka...
26.11.2013 15:32 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj

Ž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…

26.11.2013 17:43 Mti. | skóre: 31 | blog: Mti
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Nevim jestli su polovina, ale toto sem prehlidl a moc se omlouvam. :-(
Vidim harddisk mrzuty, jehoz hlava plotny se dotyka...
26.11.2013 20:17 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
já jsem asi ta druhá polovina - většítka jsem tam měl, ale tupě jsem nasatavoval ratio - ráno zkusím a poreferuju :(
27.11.2013 14:24 marek_hb
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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í
28.11.2013 09:59 Love_Dali | skóre: 22
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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..
5.3.2014 13:58 trubicoid2
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
tak to jsi sam aplikoval ten Linusuv patch? jinak ve vanilkovym 3.13.5 to nevidim, asi teda placebo efekt
25.11.2013 22:06 SGF
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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ěží.
25.11.2013 23:02 lertimir | skóre: 62 | blog: Par_slov
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 26.11.2013 08:23 Conscript89 | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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).
I can only show you the door. You're the one that has to walk through it.
26.11.2013 10:19 R
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Pri dd pouzi oflag=direct.
26.11.2013 09:39 filbar | skóre: 36 | blog: Denicek_programatora | Ostrava
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 25.11.2013 08:20 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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?

25.11.2013 08:52 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 25.11.2013 10:28 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Palkovice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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..
Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
25.11.2013 10:38 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 avatar 25.11.2013 11:00 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Palkovice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 :)
Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
25.11.2013 11:25 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 08:53 D. Toman
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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...
25.11.2013 12:03 Honz
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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...
25.11.2013 17:40 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
25.11.2013 17:09 Semo | skóre: 44 | blog: Semo
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
If you hold a Unix shell up to your ear, you can you hear the C.
xkucf03 avatar 25.11.2013 18:42 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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 :-)
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
25.11.2013 18:47 Tom K | skóre: 20
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
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.
echo -n "u48" | sha1sum | head -c3; echo
25.11.2013 22:46 Tomáš
Rozbalit Rozbalit vše Délka fronty
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.
26.11.2013 10:24 R
Rozbalit Rozbalit vše Re: Délka fronty
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.
26.11.2013 23:41 Tomáš
Rozbalit Rozbalit vše Re: Délka fronty

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

27.11.2013 00:56 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Délka fronty
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í.
28.11.2013 09:25 ed | skóre: 18
Rozbalit Rozbalit vše Re: Délka fronty
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 avatar 28.11.2013 09:54 Jiří Svoboda | skóre: 37 | blog: cat /dev/mind | Prostějov
Rozbalit Rozbalit vše Re: Délka fronty
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. :-)
28.11.2013 10:51 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Délka fronty

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 avatar 27.11.2013 22:38 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 11. 2013: Proč pomalá flashka zpomalí 64bitový stroj
Viď. atomické operácie, že by sa Jardík dočkal podpory v Kernely zapisovania na umierajúci formát CD?
KERNEL ULTRAS video channel >>>

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.