low_latency, aneb další křáp do křápojádra (diskuse)

[Petr Tomášek]

Když mluvíš od „distro-jádrech“, můžeš být konkrétní: které distro máš na müsli?

[kotyz]

imho je to problem vetsiny ne-li vsech

[xm]

Distribuční jádra v Arch Linuxu např. mají zapnutý forced preempt a vypnutý group cpu scheduler, takže ty by měly být na desktopu v pohodě (a dle mých zkušeností opravdu jsou, alespoň od kernelu verze cca 2.6.32, kde snad byly nějaké úpravy CFS scheduleru po tom co jim Con Kolivas s BFS natrhnul prdel ).

[Begleiter]

Distribuční jádra v Arch Linuxu... by měly být na desktopu v pohodě

Tohle potvrzuju.

[Limoto]

Někde kolem 2.6.30 jsem tím trpěl, ale v teď 2.6.32 naprosto bez problému...

[Begleiter]

Já jedu na Archlinuxu rel. krátkou dobu, takže ani nevím, co bylo v době jádra 2.6.30.

[xm]

Ony totiž ty změny v CFS scheduleru v jádře 2.6.32 mají opravdu dramatický dopad, viz třeba tenhle thread: kernel 2.6.32 will boost x264 encode speed BIG TIME for multicore CPUs

V kernelu 2.6.31 je u dotyčného enkódování x264 o 53% rychlejší:

Arch x86_64 (kernel 2.6.31.5): avg 15.99 fps Arch x86_64 (kernel 2.6.32-rc6): avg 24.45 fps

Podobné výsledky jako 2.6.32 dávaly i předchozí verze kernelu, ovšem pouze s BFS schedulerem. Právě kvůli tomu jak s BFS nakopal Con Kolivas vývojářům jádra prdel k těmhle změnám došlo...

Jinak neprojevuje se to jen u enkódování videa, ale i u přehrávání (na kernelu 2.6.31-bfs nebo 2.6.32 moje PC zvládá s ffmpeg-mt bez problémů přehrávat některá náročná 1080p x264 videa, kdežto na předchozích kernelech nebo kernelech bez BFS se to trhalo), distribuovaných výpočtů BOINC, atp.

[Luboš Doležel (Doli)]

Od doby, co mám 2.6.32 mi chladič na CPU při zátěži hučí nevídaným způsobem, takže evidentně je CPU mnohem víc využívané.

Teď aspoň vím, co za tím stojí

[michich]

A nebo máš problém, který obchází patch ACPI: fix High cpu temperature with 2.6.32, který půjde do 2.6.32.9.

[Luboš Doležel (Doli)]

Tohle je něco jinýho, tohle je problém s teplotou při idle.

[xm]

Eh, mam tam samozřejmě chybu V kernelu 2.6.32 je u dotyčného enkódování x264 o 53% rychlejší. Ale z kontextu to snad bylo jasné...

[Mandarinka]

Už si to moc nepamatuju, ale iirc byl tak velký rozdíl hlavně při vysokoroychlostních nastaveních (--preset ultrafast), která nejsou moc dobrá pro kvalitu (spíš vůbec ale theoru by to ještě natlouct mělo, haha). Nicméně počítám, že nějaké zrychlen bude i třeba na --preset slow...

[xm]

Podle mě bude rozdíl při všech nastaveních - CFS prostě neuměl dobře rozložit zátěž na vícejádrovém systému (nikdy nevytížil jádra naplno), kdežto BFS to umí (a od jádra 2.6.32 i CFS, i když BFS je na tom v jiných ohledech stále lépe).

Podobné drastické zrychlení bylo možno s BFS pozorovat i u BOINCu (distribuované výpočty jako Folding@home, atp.). A i při dekódování videa (při použití vícevláknového ffmpeg-mt - s BFS nebo jádry >= 2.6.32 u mě naprosto plynulý obraz při přehrávání 1080p videa, kdežto bez BFS nechutné trhání).

Ono je to vidět krásně i v htopu, při použití BFS a přehrávání náročného 1080p videa mám obě jádra vytížená na 100% kdežto při použití vanilla kernelu < 2.6.32 mám jádra vytížená jen okolo 60% (fluktuuje to i výš, ale tak nějak se to střídá a průměr bude okolo těch 60%).

[Grunt]

Ono je to vidět krásně i v htopu, při použití BFS a přehrávání náročného 1080p videa mám obě jádra vytížená na 100% kdežto při použití vanilla kernelu < 2.6.32 mám jádra vytížená jen okolo 60% (fluktuuje to i výš, ale tak nějak se to střídá a průměr bude okolo těch 60%).

-nosound -benchmark -vo null. Pokud je vzorek moc dlouhý, tak ještě -endpos a číslo v sekundách. Ještě bývá dobré fixnout frekvenci.

[pht]

Distribuční jádra v Arch Linuxu např. mají zapnutý forced preempt a vypnutý group cpu scheduler,

Tak to nevím od kdy, ale před půl rokem to tak nebylo.

[Limoto]

Nezkoumal jsem to, ale použitelnost systému při IO se za posledního půl roku hodně zlepšila...

[xm]

Už v době kdy si psal ten tvůj první blogpost Distribuční desktop křápojádro (což půl roku je) to tak rozhodně bylo, pamatuju si že jsem na to tenkrát koukal (a důkaz od kotyze je tam i přímo v diskuzi). Pravda CONFIG_HZ je nastaven na 300 Hz, ale to je zaprvé na vícejádrovém systému lepší hodnota než 1000 Hz a za druhé je to stejně tickless (CONFIG_NO_HZ) kernel (což je dobře, nejen kvůli výdrži baterek notebooků).

[trekker.dk]

Pravda CONFIG_HZ je nastaven na 300 Hz, ale to je zaprvé na vícejádrovém systému lepší hodnota než 1000 Hz a za druhé je to stejně tickless (CONFIG_NO_HZ) kernel

Pokud to náhodou nevíš, tickless kernel se týká jenom situace, kdy nic neběží. Vzhledem k tomu, že se bavíme o výkonností při zatížení, tak to asi nebude ten případ.

[xm]

Ano, ale tickless kernel v některých situacích vnáší další latence, proto jsem to také zmiňoval. Jinak viz první poznámka - na vícejádrovém systému už nadělá 1000 Hz víc škody než užitku.

[pht]

Jinak viz první poznámka - na vícejádrovém systému už nadělá 1000 Hz víc škody než užitku.

Zajímavé, proč?

důkaz od kotyze je tam i přímo v diskuzi

Hmm, důkaz místo slibů? Tak to musí být ještě v něčem dalším (možná v tom hz? nebo preempt rcu?), protože zrovna na -arch jádru to křápuje téměř všude kde jsem byl.

[xm]

Zajímavé, proč?

Protože časovač funguje per-core. Tudíž se dá říct, že pokud má člověk dvoujádro a časovač 300Hz, je to efektivně jako by měl jedno jádro a časovač 600Hz. U dvoujádra tedy o 1000Hz ještě lze uvažovat (i když si nemyslím, že je to potřeba), ale u čtyřjádra už je to IMHO naprosto přehnané (nevýhody - tedy snížená propustnost při vyšších Hz - už převýší výhody).

Hmm, důkaz místo slibů? Tak to musí být ještě v něčem dalším (možná v tom hz? nebo preempt rcu?), protože zrovna na -arch jádru to křápuje téměř všude kde jsem byl.

Je nutné si uvědomit, že to tvé "křápochování" má dvě složky - zaprvé špatně fungující plánovač CPU (což se díky BFS změnilo a už i ve vanilla jádře 2.6.32 je CFS upraveno tak, aby se chovalo lépe), což se týkalo všech jader bez ohledu na nastavení preempce a časovače (to samozřejmě dosti podstatně pomáhalo, ale jen v rámci určitých mezí).

A pak "křápochování" když probíhá nějaké velké IO (kopírování souborů, etc.), na což sice má lepší plánovač CPU také vliv, ale ne tak markantní - pořád prakticky nikdo s určitostí neví, co to způsobuje a jak se toho problému zcela zbavit. Může to mít souvislost s určitým hardwarem (třeba špatně fungující NCQ u disku), ale spíš to bude souhra problémů (NCQ, plánovač IO, plánovač CPU, práce s pamětí a diskovou cache, atp.). Btw. údajně se tohle "křápochování" ještě markantněji projevuje na 64-bit Linuxu (ale nevím, s tím nemám moc zkušeností, jen jsem na to někde narazil při mém neúspěšném hledání řešení). Tohodle problému se zcela nezbavíš ani s tvým nastavením kernelu, pouze se ten problém více skryje (zkoušel jsem to).

[pht]

Tudíž se dá říct, že pokud má člověk dvoujádro a časovač 300Hz, je to efektivně jako by měl jedno jádro a časovač 600Hz.

Takže každé core má vlastní časovač, kterej je mimo fázi s ostatníma a kterej generuje interrupty pro všechny core? :)

Je nutné si uvědomit, že to tvé "křápochování" má dvě složky

Po tom, co zavedli low_latency tak už tři složky. Ale díky za vysvětlení. Používám pouze 64 bit systémy a je fakt, že distribuční 2.6.32 jsem ještě v ruce neměl.

A pokud něco vydatně pomáhá, nebo problém zakreje tak to stejně radši použiju, než abych jen seděl na zadku a stěžoval si.

[xm]

Takže každé core má vlastní časovač, kterej je mimo fázi s ostatníma a kterej generuje interrupty pro všechny core? :)

Nevím jak to přesně funguje (zas tak do toho nevidím), ale jsem si jistý, že mimo fázi není Jde jen o to, že _efektivně_ by se co do latencí 2 jádra s časovačem 300Hz měly rovnat 1 jádru s časovačem 600Hz.

Po tom, co zavedli low_latency tak už tři složky. Ale díky za vysvětlení. Používám pouze 64 bit systémy a je fakt, že distribuční 2.6.32 jsem ještě v ruce neměl.

Nikoliv 3 složky, stále jen 2 složky (vlastně teď už jen 1 složka, protože ten plánovač CPU už považuji za vyřešený - BFS je sice stále v mnohém lepší než CFS, chování CFS je však teď už obstojné).

To tvé low_latency je právě pokus o odstranění jedné z příčin toho "křápochování" při velkém IO (je to pouze úprava chování IO scheduleru cfq, nic jiného). Zjevně to ale není moc povedený pokus (respektive podle mailing-listu to někomu opravdu pomáhá, ale jiným to naopak situaci zhoršuje).

Btw. jestli používáš jen 64-bit systémy, pak si možná důkazem toho, že u 64-bitových systémů se to "křápochování" při velkém IO projevuje markantněji než u 32-bit systémů (jak jsem se někde dočetl, ale neověřoval jsem to).

[pht]

_efektivně_ by se co do latencí 2 jádra s časovačem 300Hz měly rovnat 1 jádru s časovačem 600Hz

Nějaký odkaz k tomu?

BFS je sice stále v mnohém lepší než CFS, chování CFS je však teď už obstojné

Hlavně, že linus je proti pluggable plánovačům, takže si na každej "test" musíme počkat jednu verzi jádra. :(

To tvé low_latency je právě pokus o odstranění jedné z příčin toho "křápochování" při velkém IO (je to pouze úprava chování IO scheduleru cfq, nic jiného).

No a jak píšu v zápisku, nechápu proč to dělají nějakým dalším patchem, kterej je navíc defaultně zaplej, místo toho aby pořádně zjistili příčinu a opravili to *v rámci* současného kódu.

[michich]

Hlavně, že linus je proti pluggable plánovačům,

Ano, ...

takže si na každej "test" musíme počkat jednu verzi jádra. :(

... ale to z toho přece nevyplývá. Testovat scheduler můžeš kdykoliv. Aplikovat na něj patch, zkompilovat, rebootnout.

Jestli fakt máte někdo spolehlivý test, ve kterém se BFS chová výrazně lépe než CFS, tak o tom dejte vědět na LKML (CC alespoň na Ingo Molnar, Peter Zijlstra, Mike Galbraith).

[michich]

Ještě doplním, že ke sledování chování CPU scheduleru se dá od 2.6.32 použít nástroj perf (perf sched record; vedle nechat běžet test; CTRL+C zastavit perf; prohlížení výsledků perf sched latency pro statistické shrnutí, nebo perf sched map či perf sched trace pro detaily).

[pht]

Testovat scheduler můžeš kdykoliv. Aplikovat na něj patch, zkompilovat, rebootnout.

Jasně že to jde, ale spousta lidí dá přednost "echo bfs >/proc/scheduler", než nějakému šaškování s překladem jádra.

Jestli fakt máte někdo spolehlivý test, ve kterém se BFS chová výrazně lépe než CFS, tak o tom dejte vědět na LKML (CC alespoň na Ingo Molnar, Peter Zijlstra, Mike Galbraith).

Pokud bych to mohl přepínat výše uvedeným způsobem tak bych si to mohl zkontrolovat, ale pokud kvůli každému testu budu muset rebootovat, tak na to seru, a stejně to pravděpodobně udělá většina jindy i akčních lidí.

[trekker.dk]

Tudíž se dá říct, že pokud má člověk dvoujádro a časovač 300Hz, je to efektivně jako by měl jedno jádro a časovač 600Hz.

Tohle tvrzení mi přijde poměrně divné... pokud běží jenom jedna úloha, tak je přerušována s frekvencí 300Hz. Když běží dvě a víc, tak je každá přerušována s frekvencí 300Hz - kde se bere těch 600Hz?

(Pokud to nicméně myslíš tak, že je zbytečné úlohu přerušovat tak často kvůli interaktivitě, když stejně většinou má jedno jádro jenom pro sebe, tak to pak OK.)

[xm]

(Pokud to nicméně myslíš tak, že je zbytečné úlohu přerušovat tak často kvůli interaktivitě, když stejně většinou má jedno jádro jenom pro sebe, tak to pak OK.)

Přesně tak, jak píšu výše jde prostě o efektivní vliv frekvencí časovače a počtu jader na latence (kde by ten vztah "frekvence časovače * počet jader" měl podle toho co jsem se dočetl a i podle mých osobních zkušeností platit).

[trekker.dk]

No to ale není přesně tak. Stejně jako výše bych poprosil o nějaký odkaz, protože počet jader na první pohled nemá na latence vliv, pokud běží maximálně tolik úloh, kolik je jader. A když počet úloh bude větší než počet jader, tak by vyšší CONFIG_HZ mělo právě naopak zajistit menší latence.

[stativ]

latence možná, ale IMHO to zvyšuje režii natolik, že (teoretické) menší latence ničemu nepomůžou.

[pht]

1 ms je z hlediska procesoru věčnost.

[trekker.dk]

Režii to zvyšuje, protože se častěji spouští plánovač a úloha jako taková běží méně - celková propustnost systému klesá, ale to platí i u jednojádra a není to závislé na počtu jader. A plánovač běží řádově v mikrosekundách, takže tak hrozné to není.

[True54]

Na toto téma se s autorem těžko diskutuje. Už v minulém postu byl vyzýván k zveřejnění konkrétních podmínek (včetně distribucí), při kterých k tomu dochází, ale dozvěděli jsme se kulové. A protože jsem na žádné z dekstopových křápo-distribucí nic podobného nepotkal, těžko pak o tom diskutovat.

[pht]

To je tím, že v tomto ohledu není moc o čem diskutovat. IMHO to není problém nějaké (nejlépe jedné, abychom si zanadávali) distribuce, ale kombinace hardware + nastavení jádra. Pokud to Vy nepociťujete tak fajn, můžete jít dál, zřejmě není nic čím byste mohl k problému přispět. Pokud to někde pozorujete, můžete se přidat ...

Jo a pro úplnost, problém pozoruji na běžném hw, jako např. intel deska plus SATA disk, což je asi tak 90% všech "pracovních" PC. Distro - ubuntu, arch, mandriva.

[True54]

Někdy se stává, že počítač při diskových operacích reaguje pomaleji, například chci-li spustit nějaký další program, ale to je myslím logické, a stejné chování na mém hardware vykazují všechny edice Windows i různé Linuxové distribuce.

Ale na mém ICH10 + rychlé WD řady AAKS a AALS nemám problém hledat soubor na disku, kopírovat 80-100MB/s a desktop mi nijak nemrzne.

[pht]

Záleží co si představujete pod pojmem pomaleji. Tady mluvím o tom, že třeba jen spuštění nějakého programu, např. top (tj. jeho načtení do paměti) je operace na několik minut. Např. jednou jsem ve virtuální mašině na serveru resizoval disk a po půl hodině jsem toho raději nechal, protože zbytek serveru byl nepoužitelný. Pak jsem přeložil vlastní jádro a ta samá operace trvala tak minutu, a popřitom běžely ještě jiné diskové aktivity. Normálně by člověk řekl, že odchází disk, ale když stačí vyměnit kernel?

[True54]

To mi zní tak neuvěřitelně až vámto věřím. Ale nebude chyba spíše v hardware? Je totiž otázka, zda za to může kernel a nebo hardware, když se to děje jen omezené skupině uživatel.

[pht]

Hardware jsem přece neměnil.

V jednom případě mě to nasralo natolik, že jsem si schválně v průběhu buildu jednoho projektu zapínal a vypínal low_latency, a na práci v jiném shellu to bylo poznat.

[Mandarinka]

On tím spíš myslel, že se to zpomalení (s těmi volbami, které jste pak vypnul) možná vyskytuje jen v kombinaci s některými čipsety, takže to registruje jen část uživatelů.

[pht]

Tak to každopádně.

[msk]

např. top (tj. jeho načtení do paměti) je operace na několik minut.

Coze?!

[Limoto]

Já tomu věřím. Stalo se mi, že někdo dal na serveru nějakej chown -R na větší složku a několik minut byl server mrtvej, fungoval jedině ping...

[Václav HFechs Švirga]

J, přidávám se, kopíroval jsem nějaké soubory a počítač byl nehorázně zasekaný.

[Limoto]

Tímhle trpěl notebook...

[xm]

Známý problém (už několik let), bohužel skutečné řešení stále nikde.

Viz třeba LKML: Poor desktop responsiveness with background I/O-operations

Nebo přímo Bugzilla kernelu: Large I/O operations result in slow performance and high iowait times

Tady nepomáhá ani lepší CPU scheduler (BFS či alespoň upravené CFS v 2.6.32), ani změna IO scheduleru (deadline je sice za určitých okolností v tomto o něco lepší než cfq, ale problém existuje i s ním), ani hrátky s parametry jako dirty_background_ratio a dirty_ratio (opět lze dosáhnout jen velmi malého zlepšení). Ještě _nikde_ jsem neviděl skutečné řešení

[pht]

Díky za odkazy. Ačkoliv pánové tvrdí, že to CPU schedulerem není, tak si myslím, že je. Jinak si nedovedu vysvětlit cukání myši. Navíc mě vždy v této situaci pomohlo změnit parametry jádra orientované na CPU.

Natáhnutí dirty_writeback_centisecs a spol. má také dobrý dopad, ale spíše na využití volné paměti.

[Luk]

Ačkoliv pánové tvrdí, že to CPU schedulerem není, tak si myslím, že je. Jinak si nedovedu vysvětlit cukání myši.

Nejlepší by samozřejmě bylo to změřit pomocí latencytop

[Josef Kufner]

Jojo, takový rsync zálohující komplet celý systém dokáže taky nadělat pknou paseku a přitom zátěž CPU je kolem 20 procent...

[tomasgn]

podobne stiznosti jsem videl i na jinych forech a stezoval si i kamarad. zatimco prehravani mp3 na podstatne starsich strojich bylo jiz v davnych dobach bez problemu, dnes s debianim jadrem 2.6.26-2-686 je to tragedie (notebook Lenovo T60, Lenny). zadrhavani kurzoru je u toho taktez patrne. jadro 2.6.30-bpo.2-686 z backportu pouzivam par dni a zatim to vypada dobre, konecne si muzu i neco poslechnout.

[vain]

No dobře, takže ty operace (přehrávaní mp3) musejí něco vytěžovat nepřiměřeně ne? Nebo vše je v pohodě? Procesor se fláká? Volné paměti je dost? Disk nic "netvoří"? Já poslouchám hudbu nonstop, u toho mám zaplý i VirtualBox a brouzdám a nikdy se mi hudba nezasekla. To musí fakt kdesi cosi shnilého smrdět... jinak mám jádro 2.6.31.12.

U kopírování taky nic neobvyklého nepozoruji.

[lmanik]

taky nemam problem, archlinux - 2.6.32.8-1

[Zokl]

Je to tak, mam gentoo a co vydání nového patche je situace vždy herší a lepší. Nejlepší výkon se mi zdál v základní verzi. Nyní je verze r6 a ta je příšerná. Kdyý něco kompiluju a disk dělá tak mám problém přepnout mezi okny. Dříve to nedělalo. Spíš, když si dám verzi 2.6.31 se stejným nastavením tak je situace o poznání lepší a to mám 4 GB RAM.

Zbyněk

[kotyz]

soudruzi se asi neridi heslem "kdyz to neni rozbity tak to nespravuj" ...

[Luk]

Když to funguje, nevrtej se v tom. Vrtal ses? Jseš blb!

[pasmen]

Je teda fakt, že podobných problémů jsem si všimnul taky (pravidelně něco hledám na celém disku přes find a to je pak porod...) ale nikdy jsem to moc neřešil. Zajímalo by mě, jestli někdo nenašel podrobnější popis situace, jak by se měla jádra vyladit pro desktop apod.

[pht]

V tom předchozím článku jsem pár nastavení nastínil.

[:::]

nic takovyho se me behem poslednich min 5 let nestalo... Mas zapnuty DMA ???

[Kvakor]

Pokud SATA nejdede v PATA emulaci, tak DMA IMHO vypnout nejde.

[michich]

V komentáři na LWN.net Jens Axboe popsal, co low_latency vlastně dělá. Že to v 2.6.32 přineslo nečekané problémy, je známo. Diskutovalo se to v dlouhém threadu na LKML. Možná to bude v 2.6.33 lepší, můžeš to vyzkoušet. Každopádně tady ten problém nevyřešíš, to raději na LKML.

[pht]

Dík za odkazy. Na LKML to budu řešit až když to nepůjde vypnout. Ale naštěstí Linus má dost rozumu na to, aby něco takového schválil.

[Michal Vyskočil]

Distribuce openSUSE Factory - jádro 2.6.32-3-desktop, low_latency povoleno. Pustil jsem současně ionice -n 1 find /, rozbalení zdrojáků openjdk (taky s ionice -n 1) a zypper ref - s myší to nic neudělalo.

[Michal Vyskočil]

samozřejmě jsem myslel zypper up.

[trekker.dk]

No vidíš, díky za připomenutí, já to taky zapomněl vypnout.

[Jezekus]

Tohle jsem pozoroval i jádra 2.6.29 a lehce u jádra 2.6.31 (distribucni Fedora 10 a 12)
Na 2.6.30 (Fedora 11) je to v menší míře také, samba write (4GB) z jine masiny je smrt celeho notebooku na 15 minut
Nejvic me nastvalo, kdyz distribucni jadro zacalo umirat pri vypnuti.
Proste to chcipne s nejakou chybou v timer.c - bug uz je reportovany.
Bohuzel ne na me masine (nejak bych to obesel), ale na jednine masine me drahe polovicky
Vubec mne situace cim dal tim vic znechucuje - cim dal tim vic veci je rozbitych, mizi dobre a mnou pouzivane funkce z programu