Dotaz: Jak zlepšit odezvu pro dektop?

[Lukáš Zapletal]

Zdravím,

zajímalo by mě, jakým způsobem lze zlepšit odezvu na desktopu (parametry jádra, nastavení modulů, nastavení filesystému, aplikace...).

Odezva je při zatížení CPU nebo disku velmi špatná, například při kopírování mnoha tisíc souborů musím čekat na spuštění Midnight Commanderu i několik vteřin.

Používám jádro řady 2.6 a XFS. Díky za každý dobrý námět.

Odpovědi

[Tomáš]

?prelink třebas ještě? (FIXME)

[Jaromír Dvořáček]

Kdysi jsem si s prelinkem hral a byl IMHO zcela neucinny. Ovsem nazor je ciste subjektivni a neni potvrzen zadnymi merenimi. Take distribuce, ktera prelink pouziva (mam na mysli Fedoru) mi nikterak rychla nepripada... (tady se da ale oponovat treba Debianem, ovsem ten je IMHO rychly i bez prelinku). Proste prelink me nepresvedcil. Jedine, co mi prislo ucinne, tak bylo zkopirovani nekterych binarek a knihoven systemu do ramdisku po kazdem startu PC a tim padem rychlejsi spousteni aplikaci. Ale ta prace kolem toho...

[Heron]

U mě prelink především snížil spotřebu paměti. I když javě to stejně nepomůže. Jo a mám Fedoru. A zrychlení jsem nějaké větší nepozoroval ale na druhou stranu mi můj systém připadá docela svižný. Podle mě je Lukášův problém spíš ve filesystému (na XFS bych systém asi nedal, na data ho používám). Vyladil jsem si ext3 podle http://ck.kolivas.org/audio_hints.txt tj. noatime,writeback + commit=30,dir_index a změna je fakt znatelná.

[Lukáš Zapletal]

Zajímavý! Chystám se tam dát reiser4, jaký máte na to názor? Je vhodný na systém?

[Heron]

Zkus ho Z několika dobrých důvodů mám na / ext3. Reiserfs mám jen na /var, ten se přece jen mění o poznání častěji. Ale už k vůli divnému přístupu Hanse Raisera bych ho jako hlavní filesystem nedal.

PS: Nechce vyjít v LinuxExpressu seriál o filesystémech?

[trekker.dk]

Co se přístupu Hanse Reisera týče, přečti si Jaderné noviny

[Heron]

Hmm, nepotvrzuje to náhodou to, co jsem napsal? Tj. že pan Raiser má skutečně divný přístup.

[Lukáš Zapletal]

Někdy dokáže být komunita dost otravná. Vzpomínám ne můj nedávný docela jednoduchý optimalizační patch u knihovny Lucene, který jsem natřikrát předělával. Muselo to být prostě dokonalé, aby to bylo přijato. (Ještě to vlasntě přijato není, je tam taková drobnost - až bude čas...

Já v tom problém rozhodně nemám. To, jaký člověk je, neurčuje, jak kvalitní může psát software...

[trekker.dk]

Nebylo to myšleno jako protiargument, spíš jako doplnění

[Heron]

Aha tak promiň, byl jsem poněkud rozohněn z jiné diskuse

[trekker.dk]

Porovnání různých filesystémů je mimo jiné popsáno v seriálu "Porovnání systému Linux a FreeBSD" (nebo tak nějak), který vyšel na root.cz

Je to ale dva roky starý, takže o reiser4 se tam nic nedozvíš.

[martink]

Reiser4 jsem nikdy nezkoušel, takže z vlastní zkušenosti radit nemůžu. Slyšel jsem ale, že má velké problémy s latencí, což je pro desktop veliká nevýhoda...

Píše o tom např. Con Kolivas na http://ck.kolivas.org/audio_hints.txt:

for the moment, avoid reiser4 - it is a fast throughput filesystem but can do this at great latency expense causing bad interactivity and/or audio

[helb]

Já ho mám na /usr/portage, /home, /opt (kde mám hlavně filmy a muziku) i na root a nestěžuju si...

[Lukáš Zapletal]

The disadvantage of noatime is the last access time is not modified on files. For most things this will not matter, but there are some build scripts when compiling your own source that may depend on that particular time so it is worth being aware of.

Jak mám rozumnět tomuto? Závislosti se přeci podle časové značky čtení souboru neřídí...

[Heron]

No neřídí, nevím kde se to tam vzalo. Ale bez noatime jsem asi tak tři týdny a všechno jako předtím a žádné důležité skripty ve fedoře atime nepoužívají.

[Heron]

Na druhou stranu ten noatime zase tak hrozně výkon nepřidá. Zvlášt když je vysokej commit time. No ale větší než u XFS snad není nikde

[Luboš Doležel (Doli)]

No, noatime mám odjakživa a všechno chodí...

[Josef Kufner]

Prelink je znát při spouštění programů, které používají hodně knihoven... GTK+, Qt, atp...

[Jaromír Dvořáček]

Mozna bych se zameril na zakladni vlastnosti kernelu (DMA, chipset apod), ale IMHO jde v pripade MC o omezeni z duvodu rychlosti disku (kdyz v mc lezu do nejakyho "presouborovanyho" adresare, tak to opravdu trva).

Pokud dotaz smeruje k multitaskingu, tak trosku lepsich vysledku jsem dosahl s FreeBSD, nez s linuxem.

[Luboš Doležel (Doli)]

(Voluntary) Preemptible kernel a taky je CK patchset.

[Lukáš Zapletal]

Můžete vysvětlit, proč VPK a ne PK? Dokumentace k jádru to nevysvětluje zrovna srozumitelně:
Voluntary Kernel Preemption (Desktop) PREEMPT_VOLUNTARY
This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slighly lower throughput.
This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load.
Select this if you are building a kernel for a desktop system.
Preemptible Kernel (Low-Latency Desktop) PREEMPT
This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to run more 'smoothly' even when the system is under load, at the cost of slighly lower throughput and a slight runtime overhead to kernel code.
Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range.

Jaký máte názor na TIMER_FREQUENCY=1000 Hz?

[Luboš Doležel (Doli)]

Mám pocit, že ten Voluntary je méně preemptible než ten preemptible Nejhustší je teda Real-time preempt, ale to nVidia jen tak neustojí....

[Jakub]

Jaký máte názor na TIMER_FREQUENCY=1000 Hz?

Moje zkušenost s 1000 Hz (zkoušel jsem to v Linuxu i NetBSD, se stejným výsledkem) je ta, že ukazatel vytížení procesoru při běžných úkonech ukazuje několikanásobně vyšší hodnoty. Třeba obyčejné držení klávesy v nějakém programu - se 100 Hz je při něm vytížení procesoru 0 procent, s 1000Hz je to 20 procent. Jiní lidé třeba popisují několikanásobně vyšší vytížení procesoru při používání multimediálních aplikací (což myslím přímo nějaký vývojář kernelu připustil jako možný artefakt vyšší frekvence). Jinak jsem s 1000 Hz nějakou dramatickou změnu v rychlosti nebo odezvě na desktopu nezaznamenal, takže to vzhledem k té vysoké "režii" nemám důvod používat.

[Lukáš Zapletal]

Tak jsem udělal takový malý průzkum.

[k3]

zadnny fs nezvlada prilis dobre tisice souboru v jednom adresari. Bohuzel uz jsem videl par silencu co si mysleli, ze kdyz tam bude 900K souboru tak to pobezi svizne.

XFS se svyma bstromama spatne zvlada plochou strukturu (tj hromadu souboru v adresari) a lepe zvlada kdyz je mas rozdelene do podadresaru.

ext3 je na tom obracene :)

Pak take si nastav CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y

mno a musis mit zakompilovanou podporu pro tvuj radic disku aby jsi mohl pouzivat dma, ktere je vhodne nastavit na to nejvyssi, ktere zvladne tvuj hw..

mno a s nastavenim disku se daj delat take zajimave veci, ale je to obcas dost nebezpecne :)

[Lukáš Zapletal]

Mám oba, je to jak jsem psal - pomalá odezva při diskových operacích. A to nejen u velkého počtu souborů, stejné je to, když generuju třeba ISO. Smířím se se sníženým výkonem (XFS), ale nejde mi do hlavy, proč ty diskové operace tak blokují jiné (evidentně závislé na disku).

Myslel jsem, že v jádře bude nějaká volba - DISC SCHEDULING nebo co já vím. V operačních systémech nás učili, že na serverech se přiděluje větší procesorový okamžik, než na desktopu. Moderní systémy (tedy asi i Linux) to ale přidělují nějak dynamicky, co? Tudy tedy cesta nepovede...

[Heron]

http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-320

[alex]

Ten procesorovy cas na Linuxu se da ovlivnit pomoci voleb CONFIG_HZ_xxx, kde xxx muze byt 100, 250 nebo 1000. Pro server je vhodnejsi 100, pro desktop muzete zkusit 1000.

CONFIG_HZ_1000=y
CONFIG_HZ=1000

Default je 250. O tom, proc a jak scheduler preferuje IO procesy, si muzete precist treba v Understanding the Linux 2.6.8.1 CPU Scheduler.

[Lukáš Zapletal]

Takže jsem zkusil Voluntary Kernel Preemption a 1000 Hz a musím říci, že se doba odezvy vyditelně, a teď se podržte, zhoršila! Nyní se při těžkých diskových operacích systém přepíná například do Firefoxu i několik sekund, pokud je stránka větší (a vyžaduje více CPU).

Nevím, jestli to bylo tím přechodem Kernel Preemption -> Voluntary Kernel Preemption, nebo tou hodnotou HZ (měl jsem 250).

Nyní zkusím ještě ck-patchset a vrátím tam obyčejný Kernel Preemption. Mohl by mi někdo vysvětlit, jaký je rozdíl mezi těmi dvěma metodama?

[Luboš Doležel (Doli)]

Tak jsem zkusil 1000. Odezva sice božská, ale výkon šel dolů

[Ondroid]

Ja myslim ze se to da cekat, velka frekvence musi mit i vyssi rezii kterou si schlamstne sama pro sebe.

[Lukáš Zapletal]

No to je super, nainstalil jsem CK-PATCHSET a nyní mám k dispozici jen dvě možnosti: 100 Hz a 1000 Hz

Tak to je hustý.

[imro]

Skus nastavit vo svojom XFS filesystemu velkost inodu aspon na 512 bytes.Chce to sice znovu naformatovat disk-ale na to ti staci urobit cez tar zalohu systemu,zkopirovat ju na inu particiu,naformatovat to a preklopit to znovu na povodne miesto.

[Lukáš Zapletal]

# xfs_info /
meta-data=/                      isize=256    agcount=16, agsize=378945 blks
         =                       sectsz=512  
data     =                       bsize=4096   blocks=6063120, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=2960, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

Co to ma za vyznam, to je snad min, nez 4k - bude to tedy pomalejsi, ne?

[martink]

Jestli ještě nepoužíváš I/O scheduler cfq, tak ho doporučuju zapnout. Na desktop je IMHO vhodnější než výchozí anticipatory scheduler (některé distribuce už cfq jako výchozí I/O scheduler používají, myslím že je také defaultně zapnutý při použití ck patchsetu).

Zkontrolovat to můžeš příkazem

cat /sys/block/sda/queue/scheduler

a aktuálně používaný scheduler bude v hranatých závorkách.

Můžeš vybrat různé schedulery pro různé disky, např. příkazem

echo cfq > /sys/block/sdb/queue/scheduler

Jestli chceš použít cfq jako výchozí scheduler pro všechny disky, přidej jádru volbu elevator=cfq

[vencour]

Zatim jsem měl nastavené ...

$ cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq

[Michal Vyskočil]

Když už se otevřelo starší téma ... tak potvrzuji, I/O scheduler cfq je nutnost, alespoň pro mě. S ostatními se mi na ext3 stává přesně to samé, co popisuje Lukáš.

[zelial]

potvrzuju. po prepnuti z ac na cfq se zlepsila odezva disku pod zatezi.

[Dalibor Smolík]

jsem na desktopu, tak tisíc

[spooky.ln]

no ja myslim ze ikdyz mam vyladene jadro presne na muj notebook a specialne pro desktop tak me stejne nic nezachrani od strasne pomaleho 4200 rpm harddisku. takze muj pripad je ze pro me je nejvetsi brzda hdd. coz mi pripomina jestli nema nekdo zkusenosti s 7200 rpm hdd v notasu. to teplo uz bude muset byt neunosne ze ? predem dik.

[magla]

mam premio s hitachi 7200rpm, a teplota se pohybuje mezi 45 a 49 stupni, podle teploty okoli a jeho cinnosti.

[tom112233]

7200rpm disky pro notebooky nemají o moc lepší výkon (asi jen o 20%) než běžnější 5400rpm, ale jsou o tak o 50% dražší.

[vencour]

Mam v noťasu 1.5GB paměti a výkon disku (Toshiba 40GB/5400RPM)je

hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   1072 MB in  2.00 seconds = 536.07 MB/sec
 Timing buffered disk reads:   92 MB in  3.05 seconds =  30.14 MB/sec

[alium]

/dev/hda:
 Timing cached reads:   1628 MB in  2.00 seconds = 814.13 MB/sec
 Timing buffered disk reads:   88 MB in  3.01 seconds =  29.27 MB/sec

60GB/5400 ot Hitachi a 738 MB RAM

[Vinicius]

A jak vypada to zpomaleni? Je system pomaly jen pri spousteni aplikaci a jejich prepinani, ale po spusteni nebo prepnuti uz aplikace bezi rychle? Nebo je system pomaly celkove - plouzi se vsechno? Kolik mate RAM?

[davida]

Nevim jak XFS ale ext3 se da vyladit pomerne slusne, nekde tady na abclinuxu je navod jak nato. Co se tyce jadra zkus nitro patch, na gentoo foru mas popis featur... je to pouzitelne pro vsechny distra takze pokud nemas gentoo nemusis se obavat ze by ti to neslo.

[Heron]

Překvapivě ve FAQ