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 01:22 | Komunita

Před dvěma lety se Andrew Kelley rozhodl naplno věnovat se svému koníčku, tj. vývoji open source programovacího jazyka Zig (GitHub). Opustil své dobře placené místo v OkCupid a vytvořil si účet na Patreonu. Včera představil nadaci Zig Software Foundation zastřešující propagaci a další vývoj tohoto programovacího jazyka. Podpořit ji lze na GitHub Sponsors (aktuálně 66 % z měsíčního cíle 8 600 $).

Ladislav Hagara | Komentářů: 1
včera 22:11 | Nová verze

Byla vydána verze 2.0.10 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Nově využívá nedávno vydaný Free Pascal Compiler (FPC) 3.2.0.

Ladislav Hagara | Komentářů: 4
včera 13:00 | Komunita

Letošní konference linuxových instalatérů Linux Plumbers Conference (LPC 2020) proběhne online ve dnech 24. až 28. srpna. Vývojáři Linuxu by měli probírat také podporu programovacího jazyka Rust v linuxovém jádru [Hacker News].

Ladislav Hagara | Komentářů: 0
10.7. 17:00 | Nová verze

Multiplatformní open source počítačová hra Minetest byla vydána ve verzi 5.3.0. Jedná se o hru inspirovanou Minecraftem.

Ladislav Hagara | Komentářů: 0
10.7. 15:22 | IT novinky

Mezinárodní organizace pro sledování rotace Země a referenčních systémů (IERS) oznámila (Bulletin C 60), že letošní rok bude opět bez přestupné sekundy. Poslední vkládání přestupné sekundy proběhlo v prosinci 2016.

Ladislav Hagara | Komentářů: 1
10.7. 02:22 | Zajímavý projekt

Lze si počítačovou klávesnici navrhnout a následně vytisknout na 3D tiskárně? I spínače? James Stanley se rozhodl, že to zkusí a výsledky svého snažení zveřejňuje na svém blogu. V aktuálním příspěvku představil první funkční prototyp s třemi klávesami. Ne, nejsou to Ctrl-Alt-Delete. :-)

Ladislav Hagara | Komentářů: 36
10.7. 01:11 | Nová verze

Byla vydána nová verze 1.47 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í. Ve verzi 1.47 bude vydáno také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

Ladislav Hagara | Komentářů: 1
9.7. 13:33 | Komunita

Služba Firefox Send (zprávička) pro jednoduché a soukromé sdílení souborů s end-to-end šifrováním je dočasně pozastavena. Byla zneužívaná k šíření malwaru [reddit].

Ladislav Hagara | Komentářů: 10
9.7. 05:55 | Komunita

Google a Canonical společně oznámili možnost běhu aplikací postavených na Flutteru (Wikipedie) také na Linuxu. Na Linuxu lze tyto grafické aplikace také přímo vyvíjet. Současně byla představena pomocí Flutteru vytvořená aplikace pro správu kontaktů Flokk. Ukázka aplikace běžící na Ubuntu na YouTube. Flutter SDK i Flokk jsou již k dispozici také jako Snap balíčky na Snapcraftu.

Ladislav Hagara | Komentářů: 12
9.7. 02:22 | Komunita

Google na svém blogu věnovanému open source představil novou organizaci Open Usage Commons. Cílem této organizace je rozšířit filozofii a definici open source také na ochranné známky projektů. První tři zapojené projekty jsou Angular, Gerrit a Istio. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 1
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (22%)
 (30%)
 (4%)
 (12%)
 (17%)
 (5%)
 (12%)
 (25%)
Celkem 331 hlasů
 Komentářů: 35, poslední 9.7. 02:05
Rozcestník

Distribuční desktop křápojádro

27.7.2009 09:43 | Přečteno: 4966× | Výběrový blog

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é!

       

Hodnocení: 96 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Jakub Lucký avatar 27.7.2009 10:05 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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...
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.7.2009 10:49 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Já bych odhadoval, že preempt nedělá dobře některým proprietárním grafickým ovladačům.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 27.7.2009 11:32 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
alblaho avatar 27.7.2009 10:13 alblaho | skóre: 17 | blog: alblog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
By mě moc zajímalo, co je to za distribuci. Abych se jí vyhnul :-).
27.7.2009 10:18 prOm3TheuS | skóre: 18 | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
K tomu se připojuju, rád bych to věděl...
27.7.2009 10:48 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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*.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 17:22 Jary | skóre: 30 | blog: Jary má blog | Dům
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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." (:

.sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
27.7.2009 15:26 Kvakor
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 avatar 27.7.2009 10:16 Shadow | skóre: 25 | blog: Brainstorm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Pěkné. Copak to bylo za distribuci, mohu-li se zeptat?
If we do not believe in freedom of speech for those we despise we do not believe in it at all.
27.7.2009 11:18 1john2 | skóre: 35 | blog: jo12hn | zlín, brno
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
mám to brát jako řešení této diskuze? docela by mne to potěšilo:)
27.7.2009 11:25 bibri | skóre: 33 | Olomouc
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

Čá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.

27.7.2009 12:35 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
+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.

In Ada the typical infinite loop would normally be terminated by detonation.
thingie avatar 27.7.2009 12:44 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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íří.
Růžové lži.
27.7.2009 12:48 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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é.
In Ada the typical infinite loop would normally be terminated by detonation.
thingie avatar 27.7.2009 12:51 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ext2 asi člověk provozovat nechce. Jde jenom o tu otázku, zda i u toho ext4 fakt ten žurnál potřebuje…
Růžové lži.
27.7.2009 13:03 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ext4 bez žurnálu je stejně spolehlivé jako cokoliv jiného bez žurnálu.
In Ada the typical infinite loop would normally be terminated by detonation.
thingie avatar 27.7.2009 13:05 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Tak on pokrok mezi ext2 a ext4 není jenom žurnál.
Růžové lži.
kotyz avatar 27.7.2009 12:52 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
27.7.2009 13:02 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
kotyz avatar 27.7.2009 13:10 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 ...

Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
27.7.2009 13:17 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ano, to je přesně to křápochování :-)
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 13:18 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Z hlediska integrity metadat je.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 15:15 Kvakor
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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ý".
28.7.2009 21:14 mkmm | skóre: 11
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 avatar 28.7.2009 22:27 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
otula avatar 27.7.2009 23:21 otula | skóre: 45 | blog: otakar | Adamov
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
kotyz avatar 28.7.2009 00:48 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
No prave, ze je to prazdny, tzn. bude platit tech 60, ne?
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
kotyz avatar 28.7.2009 00:50 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ten konfigurak je prazdnej.
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
kotyz avatar 28.7.2009 00:50 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
tak je tam 60, kdyz se na to podivam tim catem
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
otula avatar 28.7.2009 07:56 otula | skóre: 45 | blog: otakar | Adamov
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Já jsem tím "prázdný" myslel swap :-D
Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
28.7.2009 08:32 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Zkuste dirty_writeback_centisecs=12000 a zapisujte na disk.
In Ada the typical infinite loop would normally be terminated by detonation.
otula avatar 28.7.2009 08:59 otula | skóre: 45 | blog: otakar | Adamov
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
28.7.2009 09:11 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
otula avatar 28.7.2009 09:18 otula | skóre: 45 | blog: otakar | Adamov
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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).
Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
kotyz avatar 28.7.2009 11:26 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
to mi posleze taky doslo :-D
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
27.7.2009 12:28 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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á.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 27.7.2009 11:23 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 11:51 bibri | skóre: 33 | Olomouc
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

>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 avatar 27.7.2009 12:12 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 ;-)
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 12:37 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 12:50 bibri | skóre: 33 | Olomouc
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

>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 avatar 27.7.2009 17:38 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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ě.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
Luk avatar 27.7.2009 18:15 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 18:44 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 27.7.2009 18:58 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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á).
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 19:13 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Taková je teorie, ale praxe je asi jiná. Zřejmě to někde drhne, když load letí na 3.0 kvůli jednomu čtení.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 27.7.2009 20:22 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Není problém v tom, že disk běží v PIO režimu (s vypnutým DMA)?
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 22:14 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 27.7.2009 23:54 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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).
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
28.7.2009 07:11 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 28.7.2009 12:08 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
28.7.2009 19:50 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 28.7.2009 20:42 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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í.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
28.7.2009 21:22 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 28.7.2009 23:27 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 :-D
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
29.7.2009 07:16 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 29.7.2009 12:39 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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é.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
29.7.2009 17:01 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 29.7.2009 17:37 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Nebo přinejmenším stejný filesystém na disku, protože ten může hrát významnou roli.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
29.7.2009 18:29 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Podle mých zkušeností a diskuse se to stává nejméně na ext3 a xfs.
In Ada the typical infinite loop would normally be terminated by detonation.
Luk avatar 29.7.2009 18:35 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Já používám zrovna právě ext3, zatímco třeba Reiser4 jsem nikdy nezkoušel.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
29.7.2009 10:47 #Tom | skóre: 32 | blog: Inspirace, aneb co jsem kde vyhrabal
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 avatar 29.7.2009 12:39 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
29.7.2009 13:28 #Tom | skóre: 32 | blog: Inspirace, aneb co jsem kde vyhrabal
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
29.7.2009 18:31 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 :)
USE="-gnome -kde";turris
alblaho avatar 27.7.2009 12:57 alblaho | skóre: 17 | blog: alblog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
27.7.2009 13:26 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

28.7.2009 13:52 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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é"

Quando omni flunkus moritati
Luk avatar 28.7.2009 14:33 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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í).
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 12:39 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 12:42 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 13:09 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 13:23 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Zátěž je právě v tom, že to ženete přes raid subsystem přičemž je to zbytečné.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 13:27 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

Hmm o 2 paralelnych swapkach som este nepocul...

27.7.2009 15:00 Kvakor
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Všechny swapy se stejnou prioritou jedou paralelně, stačí jí jen explicitně nastavit.
Michal Fecko avatar 27.7.2009 15:55 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 avatar 27.7.2009 16:06 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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šší? :-)
Růžové lži.
Michal Fecko avatar 27.7.2009 16:09 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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)... ;-)
28.7.2009 02:41 Petr_N | skóre: 3 | Všetaty
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 18:39 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ano jsou.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 12:46 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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í.
In Ada the typical infinite loop would normally be terminated by detonation.
28.7.2009 23:41 eoj
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 avatar 29.7.2009 00:16 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
???

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ě?
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 12:06 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 12:40 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 14:10 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 15:45 Kvakor
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 :-)
27.7.2009 18:41 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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?
In Ada the typical infinite loop would normally be terminated by detonation.
28.7.2009 12:30 Kvakor
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
27.7.2009 12:35 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 12:43 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 :-)
In Ada the typical infinite loop would normally be terminated by detonation.
27.7.2009 13:08 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

Mam JFS :)

kotyz avatar 27.7.2009 13:17 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.

Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
27.7.2009 13:20 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

27.7.2009 13:26 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.)
In Ada the typical infinite loop would normally be terminated by detonation.
kotyz avatar 27.7.2009 13:52 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
U xfs sem to vedel, ale myslel sem ze jfs neni stejnej pripad. O jak sem se mylil ...
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
thingie avatar 27.7.2009 13:53 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
On je to případ plusminus všech FS, asi.
Růžové lži.
kotyz avatar 27.7.2009 14:02 kotyz | skóre: 25 | blog: kotyzblog | Radnice
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Az na ext3 asi :-D
Mul-ti-pass! | Hrdý člen KERNEL ULTRAS. | Furry/Brony/Otaku | Nemám čas ztrácet čas. | In 'pacman -Syu' we trust!
27.7.2009 15:08 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

 

27.7.2009 15:32 podlesh | skóre: 38 | Freiburg im Breisgau
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
27.7.2009 15:09 Miso
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

No ja odporucam UPS ku kazdemu PC :-)

27.7.2009 15:03 Petr "Glubo" Sýkora | skóre: 21 | blog: Glubnik
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ještě, že pseudo UPS je součást notebooku :-)
„O mrtvých jen v dobrém." „Pojďme se bavit o Stalinovi."
Jan Drábek avatar 27.7.2009 13:01 Jan Drábek | skóre: 41 | blog: Tartar | Brno
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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.

01010010 01000101 01010000 01101100 01001001 00110010 01000100 01100101 01010110
27.7.2009 13:22 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
frEon avatar 27.7.2009 15:22 frEon | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Talking about music is like dancing to architecture.
Luk avatar 27.7.2009 16:53 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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).
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
28.7.2009 18:07 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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ě.
make menuconfig, not war!
Luk avatar 28.7.2009 20:08 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Reiser4 jsem nikdy nezkoušel, takže nevím. Porovnával jsem chování s ext3 (možná i s ext2, už nevím).
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
28.7.2009 20:24 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
make menuconfig, not war!
Nicky726 avatar 27.7.2009 13:36 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
27.7.2009 13:39 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
In Ada the typical infinite loop would normally be terminated by detonation.
Nicky726 avatar 27.7.2009 13:43 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
27.7.2009 15:39 miro
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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 avatar 27.7.2009 15:49 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 :-))
27.7.2009 16:10 miro
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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 avatar 27.7.2009 16:14 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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...
27.7.2009 21:34 marallo | skóre: 4 | blog: marallo | Dubnica nad Vahom
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

 

diakritiku neuznavam, a na chyby kaslem...
28.7.2009 09:46 R
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

28.7.2009 10:11 #Tom | skóre: 32 | blog: Inspirace, aneb co jsem kde vyhrabal
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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. :)
28.7.2009 23:37 eoj
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
29.7.2009 10:44 #Tom | skóre: 32 | blog: Inspirace, aneb co jsem kde vyhrabal
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Kterých Windows se to týká?
28.7.2009 23:31 eoj
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Kdepak, mi to chodilo parádně.
otula avatar 28.7.2009 10:17 otula | skóre: 45 | blog: otakar | Adamov
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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ě ;-)
Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
27.7.2009 15:51 #Tom | skóre: 32 | blog: Inspirace, aneb co jsem kde vyhrabal
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
27.7.2009 16:32 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

 

Co je CONFIG_PREEMPT_VOLUNTARY  a k čemu slouží?

 

Luk avatar 27.7.2009 16:58 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
27.7.2009 17:17 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

Michal Fecko avatar 27.7.2009 17:17 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Desktop/Server?
27.7.2009 17:21 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

Michal Fecko avatar 27.7.2009 17:27 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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...
27.7.2009 17:38 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

Ž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 avatar 27.7.2009 17:46 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
Michal Fecko avatar 27.7.2009 17:00 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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...)
27.7.2009 17:14 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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 avatar 27.7.2009 17:17 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
No ok, budiž odpustené :-D
otasomil avatar 27.7.2009 17:23 otasomil | skóre: 38 | blog: puppylinux
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

K čemu hudba, která nevede k extázi... Stop MDMA !!! I spam umí být roztomilý
Michal Fecko avatar 27.7.2009 17:36 Michal Fecko | skóre: 31 | blog: Poznámkový blog
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Evolučná teória platí neustále... Ostanú len najlepší...
thingie avatar 27.7.2009 17:40 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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.
Růžové lži.
otasomil avatar 27.7.2009 18:35 otasomil | skóre: 38 | blog: puppylinux
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

K čemu hudba, která nevede k extázi... Stop MDMA !!! I spam umí být roztomilý
thingie avatar 27.7.2009 18:39 thingie | skóre: 8
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
No, a to je přesně ten reprezentativní příklad jediné IO operace kterou kdy kdo vůbec může chtít dělat!
Růžové lži.
28.7.2009 11:39 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 ....
USE="-gnome -kde";turris
28.7.2009 19:13 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Možná distro, které tímto netrpí by dafult...
Přidej se k odporu proti eko-fanatismu! Konzumuj prémiové informace plné zdravého rozumu a vyhýbej se těm nevhodným!
Jakub Lucký avatar 28.7.2009 20:07 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
Ale nastavení jádra má stejné jako ostatní? Takže kde jinde by byl problém?
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
29.7.2009 18:33 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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 ....
USE="-gnome -kde";turris
30.7.2009 19:38 brm
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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

31.7.2009 18:49 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro
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
USE="-gnome -kde";turris
4.8.2009 21:09 Andrej | skóre: 47 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Distribuční desktop křápojádro

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.

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

Založit nové vláknoNahoru

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