Linux 2.6.31 (diskuse)

[David Watzke]

No konečně, Con hned vydal BFS pro .31, takže už kompiluju

[progdan]

Podle benchmarku prej zatim nic moc.

[ehm]

CK patch je pro nízkou latenci desktopu, proto má výkonové regrese v testech spíše měřících výkon v serverových aplikacích, zatímco současná jádra jsou spíše navržena pro dobré škálování výkonu na mnohaprocesorových systémech a desktop tím těžce trpí. Na desktopu uvítám necukající se kurzor, plynulé audio/video a okamžitou reakci gui i při vysoké zátěži a oželím nějaké to procento výkonu. Si dohledej diskuse k tomuto tématu zde na ABCLinuxu.

[Nicco]

Presne na toto cakam uz roky. Idem pohladat tu diskusiu.

[Peter Fodrek]

Podla mna je to cele o tomto povodnone povazovanom za nezmysel

Síťové ovladače již nějaký čas používají čím dál tím hůře pojmenované rozhraní NAPI („nové API“). NAPI umožňuje síťovému ovladači vypnout přerušení od rozhraní a přejít do dotazovacího [polling] režimu. Dotazování je obecně považováno za špatnou věc, ale problém je to ve skutečnosti jenom v případě, když dotaz nezjistí žádnou užitečnou práci. U vytíženého síťového rozhraní vždy budou nějaké pakety, které je potřeba zpracovat, takže „dotazovat se“ v tomto případě znamená „pustit se do vyřízení nahromaděné práce“. A když je vždy nějaká práce, přerušení informující systém o tomto faktu jsou jenom šumem navíc. Jonathan Corbet, autor tohoto článku, rád takovou situaci přirovnává k upozornění na nový e-mail; každý, kdo dostává větší množství e-mailů, takové upozorňování pravděpodobně vypne. Ruší a když se dotyčný dostane k tomu, aby se podíval do pošty, pravděpodobně vždycky nějaký nový e-mail najde.

http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-12.-8.-2009

 

[bender]

Ten benchmark nebyl k desktopu zrovna fér

[xm]

Ty Ingovy benchmarky jsou zcela zcestné, ale to se dalo očekávat Rozdíl v interaktivitě/latencích desktopu mezi originálním CFS a Kolivovým BFS je vidět na první pohled (a to velmi výrazně, hlavně pod zátěží), samozřejmě ve prospěch BFS. Syntetické benchmarky mě tedy absolutně nezajímají :-P

Btw. vyšel už např. i androidí CyanogenMod ROM pro HTC Dream (G1) a HTC Magic s kernelem s BFS a lidé to popisují jako by měli nový telefon s podstatně výkonějším procesorem, ten rozdíl je prý přímo propastný (osobně mám HTC Hero, takže jsem to nezkoušel, ale když vidím jaký je ten rozdíl i na výkoném desktopu, tak tomu naprosto věřím).

[Nicco]

To stoji za vyskusanie, z popisu to vyzera, ako revolucia v Linux desktope a zeby sa konecne Linux vyrovnal vo vykone GUI Windowsu? Ako ale pride user k tomu, aby mal jadro desktopove, alebo serverove, ked si stiahne napr buduce opensuse?

[Petr]

To je to na co jsem se ptal níže, já taky používám openSUSE a dost by se mi líbilo, kdyby mi instalátor dal vybrat, ideálně s krátkým popisem, co která volba znamená, tj. jedno vhodné pro server/nižní interaktivita, druhé pro desktop/nižší výkon serverových aplikací.

Jenže v dnešní době pitomých syntetických benchmarků, kdy např. Phoronix porovnává distribuce podle výkonu a to testy, které jsou normálnímu uživateli uplně ukradené to vidím dost bledě. Prostě co na tom, že kliknete na menu a ono se 3s nic neděje, hlavně že to udělalo o 1000 dotazů do databáze (kterou nikdy nepoužijete) více.

[ehm]

Zbývá jen buď sám si ručně opatchovat a zkompilovat vanilku, nebo Gentoo useři (i když vlastně všichni Linuxáci) mohou použít zen-sources http://forums.gentoo.org/viewtopic-t-789040.html

[Peter Fodrek]

Myslim si, ze toto(patchovanie kernelu pri boote ) je riesenie...

LWN: Thomas mi jednou říkal o schématu, ve kterém by se rtmutexy patchovaly do/z běžícího jádra během bootu, což by distributorům umožnilo dodávat jediné jádro, které by mohlo běžet buď v realtimovém, nebo "normáním" režimu. Je to stále něco, na čem pracujete?

Thomas: Momentálně na tom nepracujeme, ale je to stále na seznamu věcí, které je potřeba prozkoumat.

http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-18.-2.-2009

pouzivat chcu toto ...

 

Rebootovat systém kvůli aplikování bezpečnostní aktualizace je nepříjemnost. V některých případech je to dokonce horší než nepříjemnost; z různých důvodů nelze mnoho systémů vůbec vypnout bez narušení práce, kterou mají dělat. V dubnu se Jaderné noviny dívaly na Ksplice, mechanismus, který umožňuje instalaci jaderných aktualizací bez potřeby rebootovat systém. Od té doby práce na Ksplice pokračovala, byla zaslána nová verze a projekt se začíná pohybovat směrem k začlenění do jádra. Je tedy na místě další pohled.

Hlavním myšlenka Ksplice zůstává stejná: když je mu dán strom zdrojových kódů a patch, přeloží jádro jak s, tak bez patche a hledá rozdíly. Za tímto účelem je postup při překladu modifikován tak, aby každá funkce a datová struktura byly ve své vlastní spustitelné sekci. To je pro překladač a linker poněkud obtížnější, ale vývojáři jsou na potíže, které těmto nástrojům způsobí, výrazně necitliví. Když jsou věci takto rozděleny, je relativně jednoduché identifikovat minimální sadu změn v binárním obrazu jádra, kterou patch způsobí. S trochou opatrnosti potom Ksplice může patchovat nový kód do běžícího jádra. Když je to dokončeno, staré jádro používá nový kód bez nutnosti rebootu.

http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-26.-11.-2008

[Grunt]

To stoji za vyskusanie, z popisu to vyzera, ako revolucia v Linux desktope a zeby sa konecne Linux vyrovnal vo vykone GUI Windowsu?

Ano. Opravdu. Za posledních 10 let v Linuxu nebylo nic revolučnějšího. Ach jo. Je vůbec něco na co scheduler není lékem? A nebo už by se spíš měl jít někdo konečně léčit?

[trekker.dk]

No náhodou štěstí, že ten nový plánovač tady je. Zrovna dneska mi lagnula myš, když jsem na čtyřjádře měl load 6. Hned zítra to zkompilátoruju, aby myš byla svižnější a já na ní nemusel čtvrt vteřiny jednou za půl roku čekat.

[Grunt]

Ještě by mě zajímalo co to ten blábol jako výkon GUI vlastně je. A je vůbec něco co se výkonem nedá popsat?

[Martin Mareš]

Ty Ingovy benchmarky jsou zcela zcestné

V čem vlastně? Nepokrývají sice všechny situace (a interaktivitu měří asi jenom pipe benchmark), ale jasně ukazují, že existují případy (a na desktopu mohou bez problémů nastat), ve kterých BFS naprosto propadne.

Napsat scheduler, který je někdy lepší a někdy výrazně horší než defaultní, není žádné velké umění. Zato napsat takový, který interaktivní odezvu zlepší a nic dalšího podstatně nezhorší (řekněme jenom o procenta) ...

[belisarivs]

Pointa je v tom, ze BFS obetuje vykon ve prospech nizsi latence.

Cili kompilace kernelu nutne vyjde hure (tim spise na NUMA procesorech, na krete BFS nebyl psan), ale rychlost desktopu ma byt (a dle odezev tady i je) vyssi. Tohle ale uz nemuzes benchmarkovat.

[trekker.dk]

Tohle ale uz nemuzes benchmarkovat.

Jistě že ne. "Nainstaloval jsem si jiný plánovač a hned mám pocit, že máš všechno rychlejší odezvu", se benchmarkuje opravdu špatně.

[Martin Mareš]

Pointa je v tom, ze BFS obetuje vykon ve prospech nizsi latence.

Jenže Ingovy testy jasně ukazují, že toho výkonu jednak obětuje strašně moc (ne jednotky procent, ale často desítky) a druhak že latenci v některých případech uškodí.

Osobně BFS považuji spíš za šťouchanec, který může schedulerové hackery upozornit na to, že některé věci lze dělat ještě lépe, než za použitelný scheduler.

Tohle ale uz nemuzes benchmarkovat.

Proč bych nemohl? Latence přeci je objektivně měřitelná veličina.

[moo]

mas tiez taky "desktop"? ja nie a obavam sa, ze mnoho inych tiez nie

[David Watzke]

Tak to nevím, když budu mít nějaký zajímavý poznatky, tak o tom napíšu do blogu, ale zatím mi to přijde stejný. Kdyby mi to jádro někdo tajně vyměnil za zády, když se nedívám, tak bych na to asi nepřišel. Zatím...

[David Watzke]

I když, na druhej pohled, když to tak zkouším, tak se to hejbe o dost rychlejš... teď myslím hlavně odezvu GUI.

[Clarke]

Zkousel jste to nekdo na Gentoo a gentoo-sources-2.6.31? Me se ten patch moc nedari aplikovat

biohazard linux # patch -p1 < /home/jirka/download/2.6.31-sched-bfs-211.patch                 
patching file Documentation/sysctl/kernel.txt                                                 
patching file fs/pipe.c                                                                       
patching file include/linux/init_task.h                                                       
patching file include/linux/sched.h                                                           
patching file kernel/sched.c                                                                  
patching file kernel/sysctl.c                                                                 
Hunk #3 succeeded at 259 (offset 18 lines).                                                   
Hunk #4 succeeded at 692 (offset 18 lines).                                                   
patching file kernel/workqueue.c                                                              
patching file kernel/sched_fair.c                                                             
patching file kernel/sched_idletask.c                                                         
patching file kernel/sched_rt.c                                                               
patching file kernel/sched_bfs.c                                                              
patching file kernel/Makefile                                                                 
patching file kernel/kthread.c                                                                
patching file kernel/posix-cpu-timers.c                                                       
patching file kernel/exit.c                                                                   
patching file kernel/fork.c                                                                   
patching file mm/oom_kill.c                                                                   
patching file init/Kconfig                                                                    
patching file kernel/delayacct.c                                                              
patching file kernel/trace/trace.c                                                            
patching file fs/proc/base.c                                                                  
patching file kernel/sched_debug.c                                                            
patching file include/linux/ioprio.h                                                          
patching file Makefile                                                                        
Hunk #1 FAILED at 1.                                                                          
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej                                 
patching file kernel/Kconfig.preempt

[SAM:]

Rozjeto na gentoo s vanilla-sources. Šlape to pěkně. Subjektivně je odezva systému zaznamenatelně lepší (KDE 4.3.1). Docela si libuji. Konečně slušně svižný desktop.

[Clarke]

dik za tip

[Prokop Mikule]

Jen aby to nebyl placebo efekt :)

[ehm]

Není, notes s Celeronem na 600 MHz 188 MB ram je najednou použitelný, i když se kompiluje nějaký balíček (mám tu Gentoo). Fakt je to "k..va" znát. Plynulý kurzor i pri max vytížení. Použiji i na desktopu (quadcore 4GB ram). Sláva Conu Kolivasovi. Jeho spor se zbytkem kernel teamu o plánovač je proste desktop versus server. Je vidět, že většina vývojářů pracuje pro společnosti dodávající servery. A pro ně je škálování výkonu modla, které obětují vše. Ješte že si Con koupil novou mašinu a potřeboval nové jádro. Teď s toho máme na užitek i my ostatní.

[trekker.dk]

Fakt nepochopím, proč je ten "plynulý kurzor" taková modla. Když odhlédnu od toho, že v diskuzi popisované problémy nepozoruju (až na výjimky, jako když se vypíná swap a počítač se na 100% věnuje práci s diskem), tak bych si myslel, že důležitější je, že když tím kurzorem na něco kliknu, aby se to udělalo rychle.

Ten BFS patch sice zajistí, že (prý) počítač reaguje plynuleji, ale potom mu dýl trvá, než udělá tu práci. Já radši, když se práce dělá rychleji.

[Grunt]

Nehledě na to, že BFS pěkně žere. Člověk spustí prohlížeč a díky flashy je jedno jádro kompletně busy.

[Bilbo]

Pokud spustim 4-5 procesu snazici se urvat CPU "co to jde" (Staci pustit paralelne dvoje kopirovani z jednoho sifrovaneho disku do druheho) tak to chvilema konci tak, ze se kurzor prekresluje jen 5x

Coz neni nic moc, ja casto chci behem kopirovani i neco delat, takze bych ocenil rychlejsi odezvu interaktivnich aplikaci (vcetne toho kurzoru, pokud se kurzor prekresluje jen 3x za sekundu, je dost tezke se s nim nekam trefit) i za cenu, ze to kopirovani bude trvat o neco malo dele)

[trekker.dk]

Pokud spustím 13 procesů, co se snaží urvat CPU "co to jde" (paralelní kódování hudby do ogg), tak žádný podobný problém nepozoruji. Totéž platí pro překlad jádra s make -j6. Podotýkám, že mám Debian a jádro z kernel.org, takže vylepšení pro interaktivitu bych v tom fakt nehledal.

Asi kucí děláte někde něco špatně.

[Bilbo]

make -j6? Predpokladam tedy ctyrjadro. Mozna bude muj problem take zcasti zpusobeny tim, ze mam stale jeste postarsi jednojadrovy procesor. Ale i tak by se mohly interaktivni veci (cili neco co zere malo CPU, ale casteji) dostat nejak inteligentneji v planovaci na tu chvilku casteji k CPU

[trekker.dk]

Ano, čtyřjádro. Na dvoujádru jsem používal make -j3 a taky žádný problém.

Uznávám, na postarším Athlonu XP se občas nějaké trhání vyskytlo, ale to bylo za dob jádra 2.6.8 (od té doby jsme trochu dál, že) a ještě jenom při velkém vytížení IDE disku. (A i v takové situace na tom byl Linux lépe, než Mofty - když jsem v moftech "vypaloval" obraz CD na disk, tak se na odezvu kurzoru myši čekalo kolem vteřiny)

[Clarke]

Asi neco delam spatne... Mel bych to pak hledat v Enable the block layer --> IO Schedulers ??
zkousel jsem s vanilla-sources-2.6.31-rc9

[SAM:]

Pokud se nepletu, tak by nemělo být potrřeba to někde zapínat?!

[belisarivs]

Planovac (neplest s I/O schedulerem) mas jenom jeden. Patch proste nahradi jeden planovac druhym.

[Clarke]

tak v tom byl problem mezi klavesnici a zidli.
hledal jsem co tam nebylo, takze patch mi sel aplikovat i na gentoo-sources-2.6.31 a po zkompilovani jede
dik vsem.

[Dragon Jake]

Projdi si ten Makefile.rej, není to nic závažného. BFS patch jen přidává vlastní suffix ke kernel verzi, Gentoo patche ho samozřejmě přidávají také. Takže ten failed hunk ničemu nevadí :)

[Petr]

 Je nějaké šance, že by se BFS dostalo i do normálních distribucí, např. jako volba v instalaci? Opravdu mi je jedno, jestli moje MySQL na localhostu co mám jen pro vývoj zvládne 10000 dotazů za sekundu nebo 15000, ale není mi jedno, když mi myš cuká a pořád čekat na odezvu systému.

[9002]

FreeBSD

[Nicco]

FreeBSD nepoznam, ale oproti AIX a Solaris je GUI response Linuxu 100x lepsia

[BSDak]

tak po navsteve vo svete fBSD zaplaces....

[m;)]

[pasmen]

Pro Archlinux je to v AURu. Večer ten zázrak hodlám ozkoušet.

[m]

taky jsem si to chtel vyzkouset, ale neprecet jsem si config a tak jsem mel po necelych 3 hodinach jadro, ktery z moji reiserfs partisny nedokazalo nabootovat. tak ted si pockam na update na 2.6.31 a pak to zkusim znovu a lepe :)

[Nicky726]

Tak hezky hlasujte, ať se to dostane do [community], přecijen překompilovávat jádro se mi na mých stařečcích zrovna moc nechce.

[m]

v oficialnich repech to asi nebude nikdy, ale v nejakych uzivateslkych jo (mozna uz je). staci hledat...

[Ladislav Hagara]

Do Source Mage se BFS také dostalo.

Pokud lze Source Mage považovat za "normální distribuci".

[Max]

Když to tu tak čtu, tak asi zase uteču od distribučního jádra :-/
Jenomže ladit růčo ovladače na grafiku, modul do virtualboxu a ještě pár věcí, už mě to moc neba, ale co, tak nebudu aktualizovat xka, ani nic okolo a bude to :). Dle reakcí to určitě bude stát zato a nevíc kernel 2.6.30 mě dohání k šílenství :-/
Zdar Max

[al-Quaknaa]

LKLM -> LKML

[Ladislav Hagara]

Děkuji, opraveno.

[tlamik]

tak jsem aktualizoval a tohle je vysledek:

  end_request: I/O error, dev cciss/c0d1, sector 0

 end_request: I/O error, dev cciss/c0d2, sector 0

kazdou vterinu desitka radku s touhle chybou.

[trekker.dk]

Mezi jinými má v tomto jádře být podpora KMS pro karty Radeon... Podle zdrojáků tam je, ale menuconfig (s výchozí konfigurací pro x86) ji z nějakého důvodu stejně nenabízí.

[TomCat1]

Je to schované pod device drivers / staging drivers.

[R]

Lebo to zatial velmi nefunguje - vid spravicka o Fedora Testing Day, kde sa to vcera testovalo.

[trekker.dk]

Ach tak, to mě nenapadlo. (Podle cesty v adresářové struktuře zdrojáků jsem to hledal vedle KMS od Intelu)