Distribuční desktop křápojádro

27.7.2009 09:43 | Přečteno: 5077× |

Na jeden pracovní PC jsem nedávno instaloval čerstvou desktop distribuci a nestačil jsem se divit nad příšerným výkonem kdykoliv PC přistupoval na disk...

Potřeboval jsem na tom PC normálně pracovat. Pustit si na pozadí něco co počítač zvládne eventuelně sám, např. přenos 100GB pracovních dat, synchronizaci verzovacího systému, a při tom užívat moderních vymožeností kompozitního desktopu a programovat / dělat jinou práci. Bylo by mi jedno kdyby kvůli mojí práci skončil transfer dat o půl hodiny později, očekával jsem, že v souladu s normálností jádro upřednostní mou interaktivní činnost před přístupem na disk.

Výsledek byl ale přesně opačný: při větší diskové aktivitě šla interaktivní práce jemně řečeno do kytek. Cukající se myš, vstup z klávesnice čekal i několik vteřin, správce oken nebyl schopen ani přenášet focus z okna na okno v rozumné době. Tohle všechno podtrženo tím, že disková aktivita vytlačuje neaktivní procesy do swapu, čímž vyvolává další diskovou aktivitu. Tyto symptomy jsem neviděl na počítači poprvé, jal jsem se tedy zkoumat nastavení jádra.

První problém je s výše zmíněným swapem. Je principielní otázka, jestli v dnešní době čtyřgigových modulů za hubičku něco takového ještě potřebujeme, ale dejme tomu, že ano. V tom případě je alespoň vhodné posunout parametr swappiness z defaultní hodnoty 60 blíže k nule. Čím blíže je ke stovce a dále od nuly, tím víc programů putuje do swapu a tím více trpíme pokud je přepínáme.

Další problémy jsem našel v nastavení jádra: 300 Hz, voluntary preempt, group cpu scheduler ... tato vražedná kombinace zajistí, že při sebemenším náporu na hw bude z desktopu troska. Nějak mi není jasné, proč je desktopové jádro takto nastaveno, každopádně poté co jsem přeložil svoje jádro s 1000 Hz, forced preempt, bez group cpu sched, a bez zbytečných driverů a trasovacích voleb, všechny symptomy odešly. Teď můžu spustit třeba 10 diskových aktivit a zoomování desktopu je stále plynulé!

       

Komentáře

[Jakub Lucký]

trasovací věci jsou bohužel jediný způsob, jak pak může i noob podat distribuci aspoň nějaké informace o tom, proč mu to nefunguje...

Proč se nedělají desktop jádra preempt rovnou, to nevím, prý to s 1000Hz víc padá, ale nějak mi to nepřišlo...

[pht]

Já bych odhadoval, že preempt nedělá dobře některým proprietárním grafickým ovladačům.

[Luk]

To je klidně možné. Plně preemptivní jádro jsem používal zcela bez problémů (i bez problémů s mými vlastními ovladači ), ale je možné, že kód obsažený v binárním blobu se s tím nedokáže vyrovnat.

[alblaho]

By mě moc zajímalo, co je to za distribuci. Abych se jí vyhnul .

[prOm3TheuS]

K tomu se připojuju, rád bych to věděl...

[pht]

To jsem záměrně neřekl abych nevyvolal dojem že to je problém jedné distribuce. Pravda je taková, že je to tak téměř všude kam se podívám. Zrovna jsem to ověril asi na pěti "velkých". Jak to máte nastaveno vy se můžete podívat do /proc/config.gz nebo /boot/config*.

[Jary]

Takový dojem se dá omezit tím, že se to poví v článku. Mám na mysli něco jako "Myslím, že to však není problém jedné distribuce." (:

[Kvakor]

Setkal jsem se s ubuntistou, který mně pokládal za mimoně a staromilce po té, co jsem mu řekl, že si dodnes překládám vlastní jádra z vanila zdrojáků dle vlastniho configu, protože ta distribuční mi nevyhovují. A pokud si vzpomínám, na přesně tohle chování (odswapovávání aplikací a spol.) nadával

[Shadow]

Pěkné. Copak to bylo za distribuci, mohu-li se zeptat?

[1john2]

mám to brát jako řešení této diskuze? docela by mne to potěšilo:)

[bibri]

Částečně, já podle ní používám toto:

echo 10 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio
echo 10 > /proc/sys/vm/swappiness
 

+nobarrier pro ext3 a řekl bych, že je to lepší. Píše se tam (a v odkazech) i o změnách v jádře, dost to má zlepšit jádro > 2.6.30, používám ho, ale zdá se mi, že větší zlešení než jádro přinesto to přenastavení hodnot. Dále jsem si všiml zlepšení u ext4, ze které mám velmi dobrý pocit - je opravdu citelné. Podle všeho za tím jsou především jiné default hodnoty, dost by mělo jít aplikovat i na ext3.

JInak Mandriva to asi nebude, ta má v configu desktop jádra 1000Hz - bohužel swapiness je stejně debilně nastaven.

[pht]

+nobarrier pro ext3

To už můžete rovnou používat ext2, protože tím žurnál ztrácí svou podstatnou funkci. Já mám většinou XFS, které s bariérama taky pracuje. Na druhou stranu to není zas tak důležité protože bariéra generuje jen zápis na disk a ten by neměl interaktivním procesům vadit. Jediné čemu to vadí je rychlost zápisu na disk (dejme tomu v MB/s), ale to si musíte vybrat jestli chcete rychlý nebo spolehlivý zápis.

Každopádně pokud máte hodně paměti tak lze rychlosti zápisu disku výrazně pomoct pomocí parametru dirty_writeback_centisecs, což je defaultně 500 (5 sekund) a já ho zvyšuju tak na 12000 (2 minuty). Pokud chci mít něco do těch dvou minut bezpečně na disku, není nic lepšího než napsat sync manuálně (slabé povahy si na to můžou udělat klávesovou zkratku).

JInak Mandriva to asi nebude, ta má v configu desktop jádra 1000Hz

Ale má voluntary preempt a group sched asi taky.

[thingie]

Otázka je, jestli ten žurnál je fakt pro všechny třeba. Ono by to padat nemělo, a když, tak na desktopu se s jedním úplným fsck člověk možná smíří.

[pht]

K tomu je ovšem potřeba dodat, že ten fsck na ext2 obvykle po sobě zanechá spoušť v /lost+found častěji než je příjemné.

[thingie]

Ext2 asi člověk provozovat nechce. Jde jenom o tu otázku, zda i u toho ext4 fakt ten žurnál potřebuje…

[pht]

Ext4 bez žurnálu je stejně spolehlivé jako cokoliv jiného bez žurnálu.

[thingie]

Tak on pokrok mezi ext2 a ext4 není jenom žurnál.

[kotyz]

ja na archu (distribucni jadro) mam, podle config.gz nasledujici:

CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
# CONFIG_GROUP_SCHED is not set

swappiness sem nezjistil kolik je nastavenej, ale nebude moc vysokej, protoze swap je porad prazdnej.

[pht]

Jelikož jsem tento problém zažil i na archu tak bych řekl že tím trpí taky. Tyto parametry mě jen napadly jako možná příčina, ale ta skutečná může být samozřejmě jinde.

[kotyz]

Jo, taky se to cuka, kdyz treba prevadim v k9copy dvd, tak disk hrabe jako divej, cpu je pod 100% ale load je treba 4.0 nebo 5.0 a prepnuti na ff nebo prepnuti tabu ve ff je dost na dlouho a jeste se to tak pomalu prekresluje. Ale podle htopu je swap prazdnej nebo skoro prazdnej, tak kam to vsecko de? Mozna je tam naka priorita pro diskovy operace, taky ten ext3 s tou ted uz slusnou fragmentaci tomu neprida ...

Ale kdyz to nema hrabat fest na disk, tak se da bez problemu spustit kotel aplikaci naraz. BOINC mi tu trebas na pozadi bezi skoro furt a ani o nem nevim, ale kdyz to zacne makat a hrabat na disk a ja ho vypnu, nijak si nepomuzu. Kdyz palim DVD tak taky radsi nespoustim novy aplikace, jenom delam s tema staryma, abych to zbytecne nedrazdil ...

[pht]

Ano, to je přesně to křápochování

[pht]

Z hlediska integrity metadat je.

[Kvakor]

Na tohle je vhodné používat ionice - pokud má např. vypalovací program realtime prioritu, tak mu při přistupu k disku ostatní procesy vždy ustopí, naopak s nejnižší (idle) prioritou procesy čeká, dokud není disk "volný".

[mkmm]

V archu se to da obejit demonem ioniced. Spousti procesy uvedene v konfiguraku s idle io prioritou, takze to pak vubec netrha. Da se predelat i pro jina distra, nekdo v diskusi zminoval Fedoru (http://bbs.archlinux.org/viewtopic.php?id=73359).

[Nicky726]

To vypadá zajímavě. Juknu na to na starém kompu, kde mám ještě ext3, jaký vliv to má na ten problém.

[otula]

swappiness sem nezjistil kolik je nastavenej,

$ cat /proc/sys/vm/swappiness

BTW, já ho mám také pořád prázdný, a nastavený ho mám 60.

[kotyz]

No prave, ze je to prazdny, tzn. bude platit tech 60, ne?

[kotyz]

Ten konfigurak je prazdnej.

[kotyz]

tak je tam 60, kdyz se na to podivam tim catem

[otula]

Já jsem tím "prázdný" myslel swap

[pht]

Zkuste dirty_writeback_centisecs=12000 a zapisujte na disk.

[otula]

Tak samozřejmě, že když 24× prodloužím dobu, než se data uloží na disk, tak mi volná RAM při zápisu dojde určitě rychleji. Ale proč vytvářet takto umělé situace? Při výchozím nastavení nemám s RAM problém, a to běžně kopíruji velké soubory, v GIMPu či Cinepaintu otevírám datově objemné obrázky (i několik set MB velké). Narazil jsem jen jednou, když jsem omylem vyexportoval z SPP fotky v rozlišení 14Mpx (místo 4,7 Mpx) do 16bitových TIFF, spojoval jich asi 14 v Huginu (bylo to docela v pohodě, i když se mi to zdálo trochu vláčnější) a finální výtvor jsem otevřel v Cinepaintu - to trvalo fakt dlouho, patrně si sáhnul i na swap, ale hlavně Cinepaint neustál ten 2 GiB velký soubor.

[pht]

Já mám svůj dojem, že když nebudu na disk tlačit každých 5s, tak se ta paměť využije lépe. Pokud nemáte nic ve swapu tak to znamená že ji nevyužíváte.

[otula]

Jo takhle. Tak to bych mohl zvýšit tu hodnotu třeba na 1000 nebo na 2000. Ale nemyslím, že bych ji až tak nevyužíval. S diskovou cache se dostávám někam k 80 %, a využívat swap opravdu nechci, protože mám vyzkoušeno, že při jeho byť minimálním využití linuxový systém neuvěřitelně zpomalí, ačkoliv se třeba mezitím opět uvolní RAM (narozdíl od Windows nebo FreeBSD).

[kotyz]

to mi posleze taky doslo

[pht]

Podle letmého prohlédnutí dotazu asi ano. Když by se nedařilo tak postněte .config a lspci atd. a něco se s tím udělá.

[Luk]

První problém je s výše zmíněným swapem. Je principielní otázka, jestli v dnešní době čtyřgigových modulů za hubičku něco takového ještě potřebujeme, ale dejme tomu, že ano. V tom případě je alespoň vhodné posunout parametr swappiness z defaultní hodnoty 60 blíže k nule. Čím blíže je ke stovce a dále od nuly, tím víc programů putuje do swapu a tím více trpíme pokud je přepínáme.

Jsou zase lidé, kteří doporučují nastavovat swappiness na 100, aby nepoužívaná data procesů nezacláněla v paměti a místo toho se prostor využil pro diskovou cache. Každopádně obecná rada redukovat swapování mi moc moudrá nepřijde, sice paměti jsou velké, ale právě proto je výhodné je využít jako cache. Disky jsou totiž naopak stále krutě pomalé (hlavně seek time se už dlouho prakticky nezlepšuje) a proto možnost ponechat načtená data v paměti hodně zrychluje přístup. Záleží ale na tom, co člověk více potřebuje - jestli rychlejší přepínání mezi programy nebo rychlejší přístup k datům.

[bibri]

>Každopádně obecná rada redukovat swapování mi moc moudrá nepřijde, sice paměti jsou velké, ale právě proto je výhodné je využít jako cache.

Souhlasím, ale toto nesmí ovlivnit použitelnost sytému, což se na desktopu bohužel děje, protože při jakékoliv práci s diskem se okamžitě odswapují aplikace. A jako že dneska ten disk něco dělá pořád - Tracker/Beagle, stahují se torrenty, přehrávají se MP3/videa (kdo nemá neustále něco puštěno?)... A pak přijde na řadu toto:

>Disky jsou totiž naopak stále krutě pomalé (hlavně seek time se už dlouho prakticky nezlepšuje) a proto možnost ponechat načtená data v paměti hodně zrychluje přístup. Záleží ale na tom, co člověk více potřebuje - jestli rychlejší přepínání mezi programy nebo rychlejší přístup k datům.

Jak správně podotkl Petr v debatě na Rootu, daleko lépe se Linux choval na mnohem starších strojích už v roce 2000 - Windows tomu nemohly konkurovat ani náhodou! Když jsem lidem říkal, že mohou pálit, přitom mít puštěný v malém okně film a psát dokument v OOo tak mi nevěřili a když to viděli, byli naprosto hotoví, protože z Windows byli zvyklí na "max. jeden program najednou a dost". O deset let později mám s tím samým problém na Linuxu a na aktuálním hardwaru! A když mám na stole rc verzi Window 7 tak musím konstatovat, že Linux v default nastavení je oproti nim na desktopu zatraceně, ale opravdu zatraceně zabržděný!

Takže suma sumárum: cache mám rád, ale vocamcáď až pocamcáď. Odezvu aplikací na desktopu chci mít okamžitou a zdaleka nejsem sám. Dost mě vytáčí, když při přepínání mezi nimi na Core2Duo 2GHz se 4GB RAM začne systém sahat na disk a trvá to třeba vteřinu. Samotná vteřina mi až tak nevadí, ale můj disk se nenudí a tak to někdy trvá třeba pět vteřin. A to už je při dnešním výkonu strojů naprosté zvěrstvo! Bohužel, jak správně píše autor v blogpostu, mají s tím dneska problém  všechna distra, která se hrdě označují přívlastkem "desktopová".

[Luk]

Míval jsem problémy se "zabetonováním" počítače s Windows při větším počtu běžících aplikací. To už dnes (= na Vistě) není. Na Linuxu to nebývalo, ale nezažívám to ani dnes. Nevím, čím to je

[pht]

Nejspíš je to tím, že máte HW dimenzovaný tak, že se tyto aspekty neprojeví. Zkuste na něj trochu přitlačit a uvidíte.

[bibri]

>Nevím, čím to je

Možná tím, že nepracuješ s velkými objemy dat (často). Já jo a celkem dlouho jsem to řešil, absolutně mi nešlo do hlavy proč mám plnou RAMku diskových keší a na aplikace musím čekat, protože jsou odswapované - přičemž jsem na ta data koupil jiné disky než na systém, zvětšil RAMKu na 4GB a pořád to byla stejná hrůza. Ale jak je patrné z diskuse na rootu, ten problém není jen o chování/nastavení keše, jsou tam i nějaké jiné problémy přímo v jádře. Ale o tom asi něco víš a do debaty se s tebou raději poštět nebudu ;).

[Luk]

Já si nemohu pomoci, ale o těch problémech stále jen čtu, než abych se s nimi osobně setkal. Mám například zálohovací server - je to stará mašina s pouhými 128 MB paměti, procesorem PIII 900 MHz a diskem Hitachi 160 GB (7200 ot., 8 MB cache). Jede tam MySQL jako replikační slave (on-line replikace řady databází, většinou InnoDB engine), z toho se dělají snapshoty, dále periodicky rsync z několika serverů, opět se snapshotuje, k tomu tam běží ještě pár dalších věcí. Je tam Debian Lenny (jádro 2.6.26). Problémy nejsou žádné, i při té trošce paměti se dá se systémem bez problémů pracovat, například vůbec nepoznám, že se zrovna dělá komprimovaný snapshot databáze. Podobně desktop - mám openSUSE 11.1 s jádrem 2.6.27 a problémy nezaznamenávám (ani na relativně pomalém notebooku). Ohledně těch problémů v jádře považuji za významné jen ty problémy s ext3, ale právě tento filesystém používám (kromě některých případů, kdy je to ext2) a funguje to v pohodě.

[Luk]

Teď jsem si jen tak čistě ze zvědavosti zkusil v openSUSE 11.1 spustit haldu aplikací (kromě jiného různé browsery a v každém otevřít něco z abíčka) a pak kopírovat 4 GB velký soubor (fyzická paměť je 2 GB). Do swapu to neodhodilo nic (využito 44 KB jako na začátku celé operace), aplikace normálně reagovaly - jednou jsem nechal kopírování dojet bez zásahu (pak jsem zkusil přepínání aplikací), podruhé jsem zkoušel s aplikacemi pracovat při kopírování. Normálně to funguje (jen během kopírování to bylo o něco pomalejší). Stroj není žádné dělo, obyčejný Core2Duo@2.66, 2 GB RAM, HDD Samsung HD753LJ 750 GB 7200 rpm 32 MB cache.

[pht]

Může to souviset s tím, že máte dvoujádro, kdežto já mám jednojádro. U Vás pokud jeden proces blokuje CPU tak druhé jádro pojede. Zkuste zapisovat paralelně na dva různé disky.

[Luk]

Druhý disk nemám (nějaký starý malý by se našel, ale nebylo by to ono). To to spíš později zkusím na notebooku s pomalým procesorem i diskem. Jinak "blokovat CPU" by nic nemělo, vždyť při čekání se přepne kontext (neběží to v činné smyčce) a samotný přenos dat jde přes DMA (zbývající režie přenosu je celkem malá).

[pht]

Taková je teorie, ale praxe je asi jiná. Zřejmě to někde drhne, když load letí na 3.0 kvůli jednomu čtení.

[Luk]

Není problém v tom, že disk běží v PIO režimu (s vypnutým DMA)?

[pht]

To snad na SATA ani neexistuje... každopádně by to žralo 100% cpu v sys, takhle to žere 100% wait.

A opět: i když jede starej disk v PIO tak se neseká myš, jen to přenáší ten soubor hodinu.

[Luk]

každopádně by to žralo 100% cpu v sys, takhle to žere 100% wait

Pokud je to tak dlouho ve wait, pak jsou jen dvě možnosti. Buď je velmi pomalý disk nebo hodně špatný plánovač. Případně kombinace obojího. Může být problém v nevhodné interakci plánovače a NCQ (plánovač to nějak poskládá a seřadí a pak si to řadič disku přerovná jinak). Takhle se těžko něco řeší, ale před jakýmkoli laděním plánovače (které je podle mého názoru spíše na škodu, výchozí hodnoty jsou nastaveny jako rozumný kompromis) je potřeba přijít na to, v čem je hlavní problém.

A opět: i když jede starej disk v PIO tak se neseká myš, jen to přenáší ten soubor hodinu.

Myš by se neměla sekat, když se čeká na blokové I/O. Myš na něm přece není závislá a během čekání na I/O může dostat spoustu času procesoru. Naopak ji může sekat činná zátěž procesoru, protože jednak X server nemusí dostávat dostatek času, ale totéž se týká i příslušného vlákna v jádře (už dost dlouho je většina kódu ve vlákně - např. kpsmoused -, v rámci obsluhy přerušení se provádí jen minimum práce).

[pht]

IMHO to je o procesoru, a to že se upřednostňuje vyřizování požadavků disku před myší / X servrem / správcem oken. Je to jen o latenci systému a tady může změna nastavení plánovače úloh a vynucená preempce velmi pomoct.

[Luk]

Pokud se čeká na vyřízení požadavků diskem, může na procesoru běžet třeba obsluha myši nebo cokoliv jiného. Problémy nastávají jen v případě, že na procesoru něco musí běžet nebo že něco neběží kvůli tomu, že narazí na zamčený přístup k nějakému prostředku.

Začneme-li se vrtat v tom, co má mít větší nebo menší prioritu, je to cesta do pekel. On totiž zápis dat na disk může být například podmínkou toho, aby se dala uvolnit operační paměť (vyčerpala se natolik, že je potřeba zapsat na disk něco, co čeká v paměti) a proto to má značnou prioritu. Podobných případů je víc.

Je to jeden z hlavních sporů vývojářů jádra, jestli si s podobnými věcmi hrát (s tím, že to pak může vyústit v řetězovou reakci, protože se bude muset takhle poupravit obrovská spousta věcí) nebo jestli to udělat tak, že se to bude chovat všeobecně dobře (byť málokdy úplně optimálně). Například Linus Torvalds by viděl nejraději, kdyby se v jádře vůbec nic nevybíralo (třeba plánovače) a nic nenastavovalo, aby bylo jádro prostě vždy připraveno rozumně fungovat. Je to dost extrémní názor, ale je to přece jen čistší řešení, než mít spousty "štelovátek", u kterých nebude nikdo vědět, jak to pro konkrétní případ správně nastavit.

[pht]

IMHO je to jednoduše o tom, že procesy tráví moc dlouhej slice ve vyřizování přerušování disku už se jim nedostane (včas) CPU na pohnutí kurzoru atd.

Univerzální nastavení bohužel neexistuje. Maximálně může být nějaký mechanizmus, který ty šoupátka adaptuje sám. Do jisté míry to dělá plánovač při určení dynamické priority úlohy.

[Luk]

IMHO je to jednoduše o tom, že procesy tráví moc dlouhej slice ve vyřizování přerušování disku už se jim nedostane (včas) CPU na pohnutí kurzoru atd.

Vyřízení přerušení od disku trvá zcela zanedbatelnou dobu. Přerušení má jen notifikační funkci. Pokud se má například něco zapsat na disk, nastaví se DMA a odešle disku příkaz. Až proběhne přenos, vygeneruje se přerušení, ovladač ho zpracuje a označí požadavek za vyřízený. Nikde se nic nezdržuje - pokud by přenos běžel v PIO režimu, ani tehdy by s tím nebyl problém, běželo by to v samostatném vlákně jádra, tedy s podrobením normálnímu plánování.

Jinak to, kolik času tráví procesor v obsluze přerušení, lze snadno sledovat. Zobrazuje to například program top, kde "hi" je čas trávený obsluhou hardwarového přerušení, "si" softwarového přerušení.

[pht]

Asi jsem se nevyjádřil dost dobře. Představte si situaci, že X server čte /dev/myš a podle toho updatuje pozici kursoru na obrazovce. To je user space záležitost, takže to dělá ve svém přiděleném cpu slice. Pokud se mu z nějakého důvodu slice nedostane včas, tak bude myš cukat. Nemám moc teď čas experimentovat a řešit proč se slice nedostává, ale jelikož je možné že tomu pomáhá nedobrovolná preempce tak je taky možné že je cpu příliš často/dlouho v kernel režimu a to nejspíše kvůli tomu disku. To je ale jen teorie a nic Vám nebrání se po tom pídit sám.

[Luk]

Představte si situaci, že X server čte /dev/myš a podle toho updatuje pozici kursoru na obrazovce. To je user space záležitost, takže to dělá ve svém přiděleném cpu slice. Pokud se mu z nějakého důvodu slice nedostane včas, tak bude myš cukat.

Jenže celý problém spočívá v tom, že běžně není důvod, aby se X server nedostával "k lizu" včas. V jádře se až na naprosto exotické situace (ke kterým běžně nedochází) nemůže stát, že by nedocházelo k přepínání kontextu dostatečně často.

Prostě ať běží libovolný počet procesů, kdy každý z nich plně vytěžuje procesor, potřebná časová kvanta pro X server se vždy najdou (mj. proto, že neinteraktivní procesy jsou dost výrazně penalizovány). Testy tohoto typu jsem kdysi dělal dost intenzivně. Dokonce jsem schválně zprasil kód ovladače síťovky (konkrétně jsem do obsluhy přerušení přidal dlouhý cyklus, ve které se procesor zdržoval), abych viděl, jaké dopady to má na systém (šlo mi tehdy hlavně o chování mého vlastního ovladače, ale při té příležitosti jsem ozkoušel i různé další věci).

Také jsem kdysi vyzkoušel fork bombu, která na WinXP způsobila docela slušný zátuh, na Linuxu byl počítač celou dobu ovladatelný a kurzor myši se pohyboval plynule.

Nemám moc teď čas experimentovat a řešit proč se slice nedostává, ale jelikož je možné že tomu pomáhá nedobrovolná preempce tak je taky možné že je cpu příliš často/dlouho v kernel režimu a to nejspíše kvůli tomu disku.

Dlouhé prodlévání v kernel režimu je téměř vždy patologické. Buď běží disková komunikace v PIO režimu nebo je tam prostě nějaký jiný problém. Může to být klidně bug v jádře, není to vyloučeno.

To je ale jen teorie a nic Vám nebrání se po tom pídit sám.

Já se po tom pídit sám nemohu, protože se s tím nesetkávám a ani neznám podmínky, za kterých k tomu dochází. A abych detailně protrasovával kód blokové vrstvy a ATA ovladačů, to tedy opravdu ne

[pht]

Prostě ať běží libovolný počet procesů, kdy každý z nich plně vytěžuje procesor, potřebná časová kvanta pro X server se vždy najdou (mj. proto, že neinteraktivní procesy jsou dost výrazně penalizovány).

Může být, že X jsou chybně zařazena jako I/O bound proces místo interaktivního, nebo že nějakým jiným záhadným činem dojde jádro k závěru, že už X-ka měly času dost.

Není to taky náhodou tak, že pokud přijde přerušení od disku v době běhu X, tak se obsluha přerušení započítá do time slice X?

Také jsem kdysi vyzkoušel fork bombu, která na WinXP způsobila docela slušný zátuh, na Linuxu byl počítač celou dobu ovladatelný a kurzor myši se pohyboval plynule.

To dost záleží na tom, jaké systémové volání jste na XP použil. Takový fork je tam dost o hovně. Každopádně já si pamatuji i na Linuxu takzvaný útok na sendmail, který dokázal zlikvidovat leckterý stroj.

Já se po tom pídit sám nemohu, protože se s tím nesetkávám a ani neznám podmínky, za kterých k tomu dochází.

Zkuste jádro nakonfigurovat podle některé té disktribuce o které se tu psalo ... arch, ubuntu, pokud možno vypněte SMP.

[Luk]

Může být, že X jsou chybně zařazena jako I/O bound proces místo interaktivního, nebo že nějakým jiným záhadným činem dojde jádro k závěru, že už X-ka měly času dost.

Než se dohadovat o tom, co by mohlo být, je nejlepší to změřit. Existuje program latencytop, který měří, jak dlouho se musí čekat z různých důvodů. Ukazuje to jak globálně, tak pro jednotlivé procesy. Jádro ovšem musí být zkompilováno s CONFIG_LATENCYTOP.

Není to taky náhodou tak, že pokud přijde přerušení od disku v době běhu X, tak se obsluha přerušení započítá do time slice X?

Upřímně řečeno, nevím, zda to tam CFS započítává. Ale protože v obsluze přerušení se u aktuálních jader prakticky nic nedělá (již dávno byla většina kódu přesunuta do pracovních front), je to v podstatě jedno. Typická doba obsluhy se bude u současných procesorů pohybovat pod úrovní 1 mikrosekundy. Čili pokud se bavíme o odezvě v řádu milisekund a více, doba obsluhy přerušení je vcelku irelevantní. Pro ověření situace (zda je doba obsluhy přerušení významná pro odezvu procesů) lze využít výše zmíněný latencytop.

To dost záleží na tom, jaké systémové volání jste na XP použil. Takový fork je tam dost o hovně.

Použil jsem standardní volání CreateProcess(). Přesněji řečeno jsem ten program ani nepsal, použil jsem to, co tu někdo zveřejnil po použití ke stejnému účelu. Ovšem ani nevím, jaké jiné volání bych měl použít, než právě toto.

Každopádně já si pamatuji i na Linuxu takzvaný útok na sendmail, který dokázal zlikvidovat leckterý stroj.

Něco takového kdysi bylo, ale jednak se jádro dost rychle mění, a také hodně záleží na tom, zda se vyčerpají nějaké prostředky (například mám v živé paměti problémy, které způsobovala Opera - nutila X server alokovat paměť pro písma, čímž se vyčerpala veškerá volná paměť, takže jádro se nejdřív dost dlouho snažilo nějakou uvolnit a nakonec to skončilo pobíjením procesů přes oom_killer, tedy pokud člověk nestihl Operu sestřelit ještě v době, dokud měl paměť k tomu, aby to mohl provést).

Zkuste jádro nakonfigurovat podle některé té disktribuce o které se tu psalo ... arch, ubuntu, pokud možno vypněte SMP.

Aby to bylo k něčemu, tak bych musel mít také stejný hardware. Takhle maximálně ztratím dost času konfigurací a kompilací jádra, abych pak testoval něco, co bude těžko srovnatelné.

[pht]

Aby to bylo k něčemu, tak bych musel mít také stejný hardware.

Možná že ne, vyskytuje se to na různých hw.

[Luk]

Nebo přinejmenším stejný filesystém na disku, protože ten může hrát významnou roli.

[pht]

Podle mých zkušeností a diskuse se to stává nejméně na ext3 a xfs.

[Luk]

Já používám zrovna právě ext3, zatímco třeba Reiser4 jsem nikdy nezkoušel.

[#Tom]

Dlouhé prodlévání v kernel režimu je téměř vždy patologické. Buď běží disková komunikace v PIO režimu nebo je tam prostě nějaký jiný problém. Může to být klidně bug v jádře, není to vyloučeno.

Toto jsem zaznamenal u poškozených disků. Systém se stal docela nepoužitelný, zejména programy běžící v X. Jádro samo změnilo režim komunikace s diskem na PIO a spojení s čekáním na vyčítání vadných sektorů udělalo své.

[Luk]

Pokud jsou vadné sektory nebo nějaký jiný problém s diskem, může to pořádně brzdit systém. Ale tohle by mělo být zjistitelné přes SMART.

[#Tom]

Bylo to tak, SMART i hlášení jádra to potvrdily. Chyba se objevila zrovna na oddílu /var, což bylo nepříjemné jednak proto, že se nedaly číst některé protokoly, tak proto, že do jiných se sice málo, ale pravidelně zapisuje, kvůli čemu ten systém velmi rychle vytuhnul.

[mimi.vx]

to je vetsina pripadu ... vadny hw .... nedavno jsem znamemu po dvou mesicich musel reklamovat disk ... zadne vadne sektory, disk se sam po pul sekunde resetoval ... z toho plynouci nepouzitelnost ve vydlich i linuxu ... linux mel tu vyhodu ze z kernel logu a smrtu slo dohledat co se deje :)

[alblaho]

Já bych ale řekl, že za to můžou aplikace. Moderní věci v Pythonu, Monu, Plazmě, wtf mají mnohem větší memory footprint než za starých dobrých časů. Zkuste si na moderním Linuxu provozovat FVWM+Netscape4+Xfig a bude to pochopitelně lítat jako blesk.

[Miso]

Cim viac sa zrychluju  pocitace tym menej maju uzivatelia trpezlivosti + su kladene ine naroky - ja prevadzkujem na C2D 5200, 4GB RAM a 2xswRAID1 s Ubuntu i386 bigmem aj 15 aplikacii naraz + napalovanie + pozeranie videa + virtualizovany Windows a ide to s velmi slusnou odozvou - prakticky za nicim necakam...

[trekker.dk]

O deset let později mám s tím samým problém na Linuxu a na aktuálním hardwaru!

Tenhle problém opravdu nemám. Jestli tam třeba náhodou nemáš něco rozbitého...

Ale OK, uznávám, že Debian není distro s přívlastkem "desktopové"

[Luk]

Ale OK, uznávám, že Debian není distro s přívlastkem "desktopové"

Ale vysloveně serverové také ne, spíš je to takový kompromisní univerzál pro všechno možné (asi trochu blíž k serverovému použití).

[Miso]

Ja mam na / a /home raid1 (JFS fs) + RAID0 ako swap - neviem si to vynachvalit...

[pht]

To moc dobře nechápu proč zatěžujete swap raidem, když můžete zapnout dva swapovací oddíly se stejnou prioritou a bude to zapisovat na obě ale bez raidu.

[Miso]

Ako zatazujem? RAID0 je swap predsa nie RAID1 ...

[pht]

Zátěž je právě v tom, že to ženete přes raid subsystem přičemž je to zbytečné.

[Miso]

Hmm o 2 paralelnych swapkach som este nepocul...

[Kvakor]

Všechny swapy se stejnou prioritou jedou paralelně, stačí jí jen explicitně nastavit.

[Michal Fecko]

Otazka znie ci 2 rovnake swap priestory na roznych diskoch (ktore zvladnu samostatne citat 90MB/s (hdparm -Tt)) su lepsim riesenim ako sw RAID1 (md1) ktorého čítací potenciál je na úrovni 228MB/s (a predpokladam že vyšší je aj yapisovací potenciál)...

[thingie]

Hm. Jakou má šanci na přežití systém, který přijde o nějaké odswapované stránky? S čím je ta šance vyšší?

[Michal Fecko]

Nechapem, ked mi nenabehne jeden disk, stale mozem pouzit raidove miesto z druheho - uz nie sice ako raid ale ako samostatny swap, to ze na swap nieco (ne) ostalo sa nedozviem - swap mam iba ako zachrannu siet (4GB RAM)...

[Petr_N]

Když ti jen nenabehne, tak je to dobré. Když ti umře za chodu serveru, tak je to horší

[pht]

Ano jsou.

[pht]

Záleží ale na tom, co člověk více potřebuje - jestli rychlejší přepínání mezi programy nebo rychlejší přístup k datům.

To je svatá pravda, na desktopu to ale je obvykle to první.

[eoj]

Každopádně obecná rada redukovat swapování mi moc moudrá nepřijde, sice paměti jsou velké, ale právě proto je výhodné je využít jako cache. Disky jsou totiž naopak stále krutě pomalé (hlavně seek time se už dlouho prakticky nezlepšuje) a proto možnost ponechat načtená data v paměti hodně zrychluje přístup.

To je snad právě ono, ne? Když to chci držet v paměti, místo odkládání na disk, tak redukuju swapování.

[Luk]

???

Jádro má v zásadě dva mechanismy, jak získávat volnou operační paměť. Jedním je swapování (přesněji řečeno uvolňování mapovaných stránek - ať už je to anonymní mapování do swapu nebo mapování do souboru), druhým uvolňování cache diskových bloků. Použití té či oné cesty záleží na tom, jak je nastavena hodnota swappiness (čím je větší, tím více se používá první způsob a naopak).

Pokud se použije první cesta, odloží se neaktivní data běžících procesů (a též se uvolní neaktivní stránky programového kódu, tj. spustitelných souborů a knihoven). Při použití druhé cesty se odstraní z paměti diskové bloky, se kterými se pracovalo.

V důsledku toho první cesta znamená, že se "vyhubí" dlouho nepoužívaná data a kód procesů. Druhá cesta znamená odstranění dat souborů, se kterými se dlouho nepracovalo. Čili jinak řečeno, v prvním případě bude návrat k plnému životu daných procesů trvat déle. Ve druhém případě bude trvat déle načítání příslušných dat z disku.

První způsob tedy více zasáhne tu situaci, kdy se často přepíná mezi řadou různých programů. Druhý zase situaci, kdy se pracuje s jedním programem, ale sahá se na mnoho různých dat na disku.

Čili pokud se třeba na počítači využívá proxy server (který má na disku nastahované spousty souborů a je žádoucí, aby si co nejvíc jejich dat držel v paměti), je lepší odswapovávat jiné procesy (které jsou potřeba málokdy). Zatímco pokud má někdo spuštěných 20 různých aplikací a různě se mezi nimi přepíná (přičemž nepotřebuje načítat moc souborů z disku), ocení spíše co nejmenší swapování. Už jsem to řekl dostatečně srozumitelně?

[Ondrej 'SanTiago' Zajicek]

> První problém je s výše zmíněným swapem. Je principielní otázka, jestli v dnešní době čtyřgigových modulů za hubičku něco takového ještě potřebujeme, ale dejme tomu, že ano

Ono to s existenci swapu prakticky nesouvisi - s omezenou pameti je vzdycky problem, zda radsi z cache uvolnit stranku A nebo stranku B, kde stranka A je zrovna nevyuzivana stranka kodu beziciho programu  a stranka B je stranka s datama, ktera prave byla zapsana na disk.

[pht]

To ano, ale někdy je ten problém pro výkon zásadní a někdy ne. Např. pokud mám 4G paměti a programy využijí 1G, z toho půlka je "neaktivní" tak je mi dost jedno, jesli mám disk cache 3G nebo 3.5G. Pokud mám paměti jen 1G tak mi to ve stejné situaci jedno není.

Navíc swap má i jiné neduhy, třeba kryprografickou nebezpečnost.

[Ondrej 'SanTiago' Zajicek]

> Navíc swap má i jiné neduhy

Sam pouzivam leta pocitac bez swapu a tak vim, ze tento problem se tim neresi. A on ani obecne moc dobre resitelny neni - pokud nekdo ma 1 GB RAM, 400 MB je obsazenych programy a on stahne a rozbali 900 MB tar archiv, tak je otazka, zda je spravne vytlacit tech 300 MB programu z RAM. Pokud to uzivatel jen na pozadi rozbaluje a pak necha lezet, tak by to spravne nebylo, pokud ale vzapeti po tom pusti na vsechna ta data grep, pak se ukaze, ze vytlacit  vsechny ty programy z RAM by byl velmi rozumny krok.

[Kvakor]

Swap se hodí vždycky, i když je paměti dost, protože obzvlšť user-friendly distribuce často spouštějí při startu všechno možné a půlka z toho často jen sedí v paměti a spí jako Plch z Alenky. Pokud se takový proces odswapuje, nijak to nevadí, protože se probouzí jen zřídka, popřípadě vůbec, a uvolněná paměť je mnohem užitečnejší.

Já osobě to řeším tak, že pro tyhle "plchy" mám swap z druhé poloviny paměti grafické karty (přes mtdblock), což zároveň velmi elegantně řeší i onen kryptografický problém

[pht]

Není jednodušší takové procesy nepouštět? Případně změřit kolik mají rss a pokud je to 20 mega tak to neřešit?

[Kvakor]

Ovšem že je, ale ne každý ví, co může ze startovacích skriptů vyhodit a co ne. Jenom pokročilí uživatelé si po instalaci vyhodí zbytečné démony, protože vědí, co je nutné mít spuštěné a se může v případěpotřeby pustit ručně.

Ale i tak jsou procesy, které většinou jen spí, ale kterých se není dobrá vzdávat - napřiklad acpid na běžném desktopu naprostou většinu doby jen spí, ale v okamžiku, kdy nastane nějaké ACPI událost, např. se stiskne tlačítko Power, se musí probudit a vykonat to, co má napsáno, nebo třeba getty, které také spí až do doby, kdy se na danou textovou konzolu potřebujete přihlásit. A právě pro takovéto procesy je dobré mít swap, kam se uklidí pokud zrovna nejsou potřeba.

[Miso]

Na distribucii mi nezalezi - vacinu kernelov si aj tak upravujem - ale aky FS?  Predpokladam ze EXT3 - netuneny

[pht]

EXT3 neumí extenty, takže pokud chcete mít kvůli gigabajtovému souboru další megabajty pomocných dat, které když se rozeserou tak máte po souboru, tak prosím

[Miso]

Mam JFS :)

[kotyz]

Taky sem mel, ale po par dnech sem se este rad vratil k ext3. Sice to bylo subjektivne sviznejsi, objektivne pri kopirovani vetsiho mnozstvi dat to bylo rychlejs hotovy a zatizilo to cpu podstatne min, ale beda jak dedek vyhodil jistic, rychlej fsck, vsechno vypadalo ok ale konfiguraky kde vynulovany, nastaveni v prdeli. Este asi jednou nebo dvakrat se to opakovalo. A stacilo par dni. Na ext3 za tech nekolik let se mi to jeste nestalo a ze tech vypadku bylo ...

Lakal mel ext4, ale co sem si precet o ty vlastnosti se zpozdenou alokaci, tak me chut presla. Sice to neni chyba ext4, ale spis tech aplikaci, ktery cekaji chovani jako od ext3, ale ja ty aplikace pouzivam a tomuhle se prave chci vyhnout. Btrfs taky vypada lakave. Zatim zustanu ve vyckavaci pozici.

[Miso]

JFS a XFS su velmi svizne (vo vseobecnosti). Ale plati stare zname - na JFS a XFS bez UPS nelez !!!

[pht]

UPS pouze zajistí dodatečné zapsání dat, pokud se to stihne, a vypnutí systému. Řekl bych, že tam moc na použitém FS nezáleží. EXT3 má pouze blbě udělané řazení operací, takže se mnohem častěji zapisuje všechno na disk, takže se může zdát, že je spolehlivější. (Než někdo vypne bariéry.)

[kotyz]

U xfs sem to vedel, ale myslel sem ze jfs neni stejnej pripad. O jak sem se mylil ...

[thingie]

On je to případ plusminus všech FS, asi.

[kotyz]

Az na ext3 asi

[Miso]

Zazil som to s aj s EXT3 - burka, nemal som UPS na tom stroji, vyplo prud - potom zacal startovat system, 3x robil kontrolu (2x sa restartoval po kontrole). Vysledok? Komplet nastavovane konfiguraky (nastavovane cca 1 hodinu pred vypadkom!!!!!!) sa ocitli v textovo-binarnom mismasi v lost+found a velke mnozstvo sluzieb nenabehlo...

 

[podlesh]

No nevím, já osobně jsem například viděl několik zbořených filesystémů po výpadcích a vždy to bylo ext3 nebo reiser (ale prehistorická verze, někdy v roce 2000). A to používám XFS řádově více než ext3.

[Miso]

No ja odporucam UPS ku kazdemu PC

[Petr "Glubo" Sýkora]

Ještě, že pseudo UPS je součást notebooku

[Jan Drábek]

A za to všechno můžou ty absurdně rovnostářské (skoro až komunistické) časovače disku (CFQ) a úloh (CFS)... Nechápu co na tom ti vývojáři jádra vidí, ale mě se v praxi neosvědčily.

[pht]

CFQ je podle mě dobrá věc. Pouze diktuje kdo se dostane na řadu pokud se vytvoří fronta I/O operací. Což jednak dělá dobře a jednak nemá s latencí myši nic společného. CFS je jiná věc, bohužel o jejích vnitřnostech toho moc nevím.

[frEon]

CFQ se mi osvedcil, ale moc dobre si pamatuju jak jsem cely naddrzeny zkousel cerstve 2.6.23 s tim novym planovacem.... Po chvili jsem se rad vratil k 2.6.22 s Kolivasovym patchsetem.

[Luk]

Pro běžnou práci na desktopu je prakticky jedno, který plánovač (ať I/O nebo procesoru) se používá. Kdysi jsem dělal srovnání (subjektivně založená, nic jsem neměřil) různých plánovačů I/O ve výchozím nastavení - s výjimkou noop (kde to bylo skutečně o něco málo pomalejší) jsem nezaznamenal žádný rozdíl. CFQ používám jako výchozí už hodně dlouho (protože Red Hat ho měl jako výchozí, přestože ve vanille to bylo jinak) a problémy s ním nejsou. Taktéž u plánovačů úloh jsem subjektivně nezaznamenal žádný rozdíl (tam samozřejmě nešlo provést srovnání se stejným jádrem, srovnávám verzi s původním plánovačem a s novým).

[M. Lox]

To hodně závisí na FS – například Anticipatory + Reiser4 je pomalu na mašli, zatímco s CFQ vše běhá krásně.

[Luk]

Reiser4 jsem nikdy nezkoušel, takže nevím. Porovnával jsem chování s ext3 (možná i s ext2, už nevím).

[M. Lox]

Tam je právě hodně znát, že ext* používá každý a tak jsou plánovače optimalizovány pro výkon právě s nimi. Výraznější (i když pořád malé) rozdíly se dají vysledovat i u ReiserFS nebo XFS.

[Nicky726]

Tak jestli dobře koukám, tak ve výchozím Archu je 300 Hz, preempt, a bez group shed. S ext3 i s jádrem .30 jsem toto chování zažíval dost citelně. Teď na ext4 mi to nepřijde vůbec tak patrné. Otázkou je jaký na to má vliv nový fs po pár dnech používání na velkém disku versus rok a půl používaný fs na disku, kde nebylo moc volného místa a jaký je vliv nyní používaného šifrování celého disku.

[pht]

Vliv by neměl být žádný. S dobře nastaveným systémem může Váš disk třeba zapisovat na telegrafní pásku a X server, který je v paměti, by neměl mít problém s posouváním kurzoru myši. Jinak ad arch viz výše.

[Nicky726]

V tom případě na to má ext4 příznivý vliv. Silné cukání jsem zažil jen, když se mi prohlížeč zbláznil při nahrávání fotek na edisk a já se ocitl s plnou 1 GB ramkou a téměř 1,5 GB ve swapu.

[miro]

Je téměř neuvěřitelné, že se tenhle blogpost objevuje přesně v den, který jsem v podstatě celý proseděl před počítačem a 90% času marně a zoufale čekal nějakou odezvu. )-:

Pár lidí tu žádalo "antitip" na distribuci, mě by naopak zajímalo, zda má někdo nějaké negativní zkušenosti s openSUSE. 11.1 mi na PIV 1,8 GHz + 384 MB RAM funguje celkem uspokojivě, zato F11 je na PIV 3 GHz + 512 MB RAM bída a utrpení. Na jiném počítači (s téměř stejným CPU) mám paměti giga a tam si F10 spokojeně přede. No chápu, že 512 MB RAM není mnoho, ale na běžnou kancelářškou práci + pár tabů ve Firefoxu... yumex je při téhle hw konfiguraci prakticky zakázaná aplikace (zajímavé, yum je ještě obstojně použitelný, navíc ten yumex mi ještě v F9 z nějakého záhadného důvodu nabíhal podstatně rychleji, když jsem si ho pustil z domu přes ssh :o))

Pokud krom Fedory trpí podobnými problémy i další mainstreamová distra, bude ten současný stav patrně velmi efektině odrazovat nové zájemce o Linux.

[Michal Fecko]

Pokud krom Fedory trpí podobnými problémy i další mainstreamová distra, bude ten současný stav patrně velmi efektině odrazovat nové zájemce o Linux.

... žiada sa mi doplniť že na desktope - na serveroch je to trochu ine (v konzole som sa s nestihanim zatial nestretol - ked neratam pripady ked nestihal framebuffer prekreslovat - ale to nebolo na servery tam framebuffer nepatri rovnako ako Xka )

[miro]

Myslím, že většina nových uživatelů nejdřív vyzkouší Linux na desktopu, potom ho případně vrhne na server. To byl aspoň můj vývoj. Ale možná jsou i tací, kteří si v Linuxu rozjedou rovnou server a na desktopu zůstanou u ikspéček.

[Michal Fecko]

To bol moj pripad - s linuxom som sa sice dostal do kontaktu na desktope (tusim r. 97/98) - ale v tom case som bol ubezpecovany ze je to serverovy OS - tak som skusal nasadenie linuxu ako server (prvy server bol tusim postaveny na Monkey Linuxe - nejake distro spustajuce sa z dosu - bezal na nom ftp a tusim aj http (?) server - fakt napamatam). Potom nasledoval Redhat, Slackware - no presiel som vsetkymi mainstream distribuciami az som skoncil u Debiana na serveroch a Ubuntu na desktopoch...

[marallo]

Monkey linux bola super vec, doteraz ho mám niekde na CDčku. Spúšťalo sa to cez dávkový súbor (tak to volali v odbornej literatúte, proste normalne *.bat) z DOSu, a chodilo to bombovo...

 

[R]

Az tak bombovo to zase nechodilo. Bolo to podstatne pomalsie ako windows na rovnakom stroji.

[#Tom]

Ono to rozšíření UMSDOS nebylo moc rychlé, ale na druhou stranu která Windows v Linuxu rozbalíte a spustíte bez emulátoru? Ve své době to byla pěkná hračka na seznámení se s Linuxem. Stačilo to rozbalit a spustit. :)

[eoj]

ale na druhou stranu která Windows v Linuxu rozbalíte a spustíte bez emulátoru

Nainstalovat systém, zabalit ho a přidat spouštěč jde kdekoliv.

[#Tom]

Kterých Windows se to týká?

[eoj]

Kdepak, mi to chodilo parádně.

[otula]

Třeba já jsem jako první před nějakými 11 lety rozjel na RedHatu PDC jakožto náhradu za nespolehlivý (a hlavně nelicencovaný) NT4 server (byla to ta doba, kdy se u nás začalo veřejně mluvit o licencích a legálním SW, tak jsem si rychle zametl před svým prahem a nemohl jsem pak pochopit, že jsem se vůbec kdy předtím trápil s Winserverem). Používat GNU/Linux na desktopu bylo opravdu jen pro silné nadšence, navíc rozchodit byť hloupou českou klávesnici, nebo vytisknout něco na tiskárně, byly úkoly pro zkušené uživatele, sehnat informace bylo složité, pokud se člověk nepohyboval v univerzitním prostředí.

Ale už tehdy jsem si všimnul paradoxu, že ačkoliv v knihách bylo psáno o těžkopádném a nenažraném KDE a lehkém svižném Gnome, realita byla opačná, a to velmi výrazně

[#Tom]

Nastavení popisované v zápisku mám stejné až na časování (250 Hz). Źádné z uvedených problémů nepozoruju ani na Intel Core2 Quad (2,8 GHz, 4 GB RAM, Linux 2.6.27.8), ani na Pentiu II (0,4 GHz, 0,25 GB RAM, Linux 2.6.29). Oba systémy jsou Debian Lenny s ručně kompilovaným jádrem a mají nejméně jeden zánovní rychlý disk.

[brm]

 

Co je CONFIG_PREEMPT_VOLUNTARY  a k čemu slouží?

 

[Luk]

Dobrovolně preemptivní jádro (RTFM - je to tam popsáno!). Zatímco u plně preemptivního jádra lze přepnout kontext kdykoliv (pokud to není explicitně zakázáno) a u nepreemptivního lze přepnout jen v uživatelském prostoru nebo když se úloha procesoru sama vzdá (např. na něco čeká), u dobrovolně preemptivního jsou definovány poměrně hojné body, kde lze kontext přepnout. . Je to prostě kompromis mezi poněkud riskantní plnou preemptivitou a nepreemptivitou s dlouhými latencemi.

[brm]

Z praktického hlediska je lepší zapnout nebo vypnout?  Kvůli minimalizaci latencí bych řekl vypnout.

[Michal Fecko]

Desktop/Server?

[brm]

Desktop. Když jsem s Linuxem začínal , byl jsem nadšen a teď  pozoruji stejné chování popisované v blogu.

[Michal Fecko]

A nebude to chovanie spôsobene rôznymi ovládačmi chipsetov, grafických kariet či iba voľbou filesystému - ja nič také nepozorujem...

[brm]

Žeby 4jádro na 2,8 Ghz 4GB ram a větší disky s větší cache  mělo horší výkon než  Celeron 466 Mhz 256 MB ram a pomalejším diskem? Na starém kompu nebyl problém s mnohahodinovou kompilací třeba OpenOffice, nijak se to neprojevilo na odezvě systému. Na nové mašině s novými jádry ( kvůli ovladačů) kompilace čehokoliv na pozadí jde hodně poznat na odezvě .

[Luk]

Ono to není vypnout/zapnout, ale je to jedna volba z uvedených tří (něco z toho musí být zapnuto). Pro desktop to dnes bývá default, pro server se často používá nepreemptivní jádro, plně preemptivní jen tam, kde je potřeba co nejmenší latence. Plně preemptivní jádro může narazit na problémy s některými exotičtějšími ovladači, které nejsou dostatečně připraveny na to, že se může kdykoli přepnout kontext.

[Michal Fecko]

Je to konfiguracna volba jadra (nastavuje sa pred kompilaciou) - viac tu - a nabudúce skús najprv hľadať (hneď prvy odkaz stryka googla to rieši...)

[brm]

Pro oba , kteří jste mi odpověděli: Děkuji, ale to RTFM si odpusťte. Četl jsem to tolikrát, kolikrát jsem kompiloval jádro (tj, za poslední 4 roky, co používám Linux minimálně 50x), ale moje czenglish není na takové  úrovni, abych plně porozuměl technickému výkladu.

[Michal Fecko]

No ok, budiž odpustené

[otasomil]

>>>jestli v dnešní době čtyřgigových modulů za hubičku

Nepotrebujem swap jiz nekolik let. Doufam ze dnes je jiz  historii.

Vase problemy se systemem jsou duvodem k tomu ze vznikaji dalsi distribuce v nichz se autor snazi aby system pracoval tak jak chce on.

[Michal Fecko]

Evolučná teória platí neustále... Ostanú len najlepší...

[thingie]

Až tak dostupná a laciná ta paměť zase taky není. Swap se stejně vyplatí, v asi každém systému najdete stránky, které se používají tak málo, že se jednou vyplatí je hodit na disk a paměť použít radši na diskovou cache nebo něco takového.

[otasomil]

>>>paměť použít radši na diskovou cache nebo něco takového.

to takhle kopirujete na externi usb disk iso soubor o velikosti 700 MB a on se Vam cely skopci do cache a az se zavre dialogove okno "kopirovani" a chcete odebrat disk tak se Vam pul minuty syncuje teprv na ten usb disk nez ho system umozni uzivateli odmountovat.

A swapfile ci swap partition uz ma odzvoneno. 2 GB RAM = karton nejhumusovejsich cigar co se daj vubec koupit

[thingie]

No, a to je přesně ten reprezentativní příklad jediné IO operace kterou kdy kdo vůbec může chtít dělat!

[mimi.vx]

zajimave .... mam 2.6.30 jadro . v systemu 2 disky + usb disk + 1 na fw .... a zadne problemy .... V jadre mam , tickless system, hpet, cfq, slub ....., jenom pri zatezi na usb dokaze system to trochu potrapit , zatimco na widlich(vista) me system prestal reagovat pri kopirovani 2Giga dat na tri pocitace pres gigovou sit ....

[kralyk z abclinuxu]

Možná distro, které tímto netrpí by dafult...

[Jakub Lucký]

Ale nastavení jádra má stejné jako ostatní? Takže kde jinde by byl problém?

[mimi.vx]

to si pis ... Gentoo ~AMD64..., jadro si stavim vlastni od dob slackware , i kdyz v gentoo je dost patchu navic narozdil od slacka ...

Ma zkusenost je ze pokud dikove operace blokuji desktop a vyrazne zpomaluji pc je neco s hw disku a nebo mb ....

[brm]

Tak sem hoď svůj  .config, ať se můžem inspirovat.

[mimi.vx]

konfiguraci mam jednoduchou ..... vse co nemam v jadre neni , krom veci pro fw a usb.... jinak amd64,tickless,1000hz , cfq a libata , bez ramfs a ramdisku......., usb,zvuk,fw je v modulech ...., powergorvernory v modulech kdyby jsem nahodou chtel preponout politiku taktovani cpu

[Andrej]

Já používám 300 Hz všude k naprosté spokojenosti. 1000 Hz podle mě dnes přináší víc škody než užitku a na nějakém čtyřjádru to platí dvojnásob.

Zmíněné potíže jsem zažil taky, ale příčina byla zcela jinde: I/O scheduler. Jako implicitní scheduler tam byl původně CFQ nebo dokonce Deadline. Například přehrávání mp3 na pozadí se při jakékoliv intenzivnější diskové aktivitě začalo trhat. Přepnutí na Anticipatory všechny tyto problémy vyřešilo. Anticipatory je sice nejnáročnější na procesor a přidává těžko předvídatelnou latenci, ale i přesto s ním mám zatím na desktopu tu nejlepší zkušenost.