[Frissítve] BFS vs. a mainline kernel ütemezője

Kernel

Con Kolivas hosszú hallgatás után nemrég egy desktop felhasználásra kihegyezett ütemezővel állt elő. A BFS névre hallgató scheduler felbukkanása felkeltette a mainline kernelben található processz ütemező szerzőjének, Molnár Ingonak figyelmét is. Ez utóbbi ütemező a Completely Fair Scheduler (CFS), amelynek létrehozásában Ingo szerint szerepet játszott Con Kolivas SD/RSDL munkája is. A BFS bejelentésekor Con említette, hogy az új ütemezője desktop típusú felhasználás esetén hoz javulást a CFS-hez képest, de sok CPU-s rendszereken (16+ CPU) már gyengébben muzsikálhat. Molnár Ingo úgy döntött, hogy leteszteli Con Brain Fuck Scheduler-jét és összehasonlítja a mainline kernel ütemezőjével.

Ingo a teszthez egy hyperthreding-es dual quad-core rendszert választott. A teszteredmények - amelyek megtalálhatók itt -, azt mutatták számára, hogy az általa használt gépen a BFS semmilyen javulást sem hozott, sőt egyes esetekben sokkal gyengébben teljesített. Ingo levelében megjegyezte, hogy Con küldjön nyugodtan patch-eket ha úgy érzi, biztosította a fejlesztőt arról, hogy figyelemmel fogják kísérni BFS munkáját és ha úgy adódik a jó ötleteket és kódokat átemelik a mainline kernelbe.

Ingo levelére válaszolva volt aki azt kérte, hogy ha teheti ismételje meg a teszteket dual core / egy processzoros rendszeren.

Más arról számolt be, hogy a Core 2 Duo processzoros gépén számos desktop alkalmazás - mplayer OpenGL renderer-rel, kompozit desktop effektek, LMMS, Doom 3 - sokkal jobban teljesítettek Con BFS ütemezőjével. A kernelfán végrehajtott "make -j 2" során a GUI szintén jobban teljesített.

Ingo levelére Con is reagált. Szerinte Ingo megtalálta azt a hardver és benchmark kombinációt, amely alátámasztja az érveit és bizonyítja, hogy milyen jó a CFS a BFS-sel szemben. Végül feltette a kérdés Ingonak, hogy tudja-e, hogy hogyan néz ki egy desktop rendszer, utalva arra, hogy a BFS desktop felhasználásra készült.

Nem sokkal ezelőtt - a korábbi felkérésre - Ingo elvégezte a teszteket egy single socket, quad-core gépen is, hogy a tesztrendszer minél jobban hasonlítson arra a gépre, amellyel Con tesztelt. Az eredmények ismét azt mutatták számára, hogy a CFS gyakorlatilag minden tesztben jobb a BFS-nél.

Ingo arra bátorított, hogy mindenki maga végezze el a teszteket és ne vegye senki sem készpénznek az állításokat.

A két thread itt és itt kezdődik.

Frissítés #1: van aki még mindig nem elégedett Ingo mérési módszereivel

( mapee v | 2009. 09. 07., h – 15:57 )

Ez így hülyeség. Keressenek 1 fügetlen és pártatlan hozzáértő tesztelőt, fog egy dual/quad core desktop gépet + egy 16+ cpu-s gépet és kiderül, hogy fekete vagy fehér.

Apple MacBook C2D 2.2Ghz 2x1G Intel X3100

( gUHU | 2009. 09. 07., h – 16:01 )

Fincsi. Lassan be tud ékelődni a joshi Bharat és a Maunika közé...

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

( zsolt | 2009. 09. 07., h – 17:25 )

Nem tudom, Ingo milyen megfontolásból mutatja magát hülyének, de a tesztjei mind tipikus szerver-alkalmazás tesztek.

Ez inkább olyan hogy mindkettőben ugyanaz a motor van de az egyik kamion (cfs -server) a másik versenyautó (bfs - desktop) a _célfüggvény_ más. Lehet hogy a kamion jobban osztja be a lóerőket és gazdaságosabb mint egy versenyautó de a versenyautó gyorsabb. Desktopon - nekem - fontosabb az hogy ha rábökök egy ikonra akkor azonnal történik valami, de egy kicsit később fejeződik be a másolás mint hogy milyen szépen osztja el a process-ek között a munkát. Kipróbáltam, _sokkal_ gyorsabban reagál az ilyenekre mint régen.

Ezért is vicces hogy Ingo olyan bechmarkot hoz fel példaként hogy a make -j16 jobban teljesít cfs alatt mint bfs alatt. Ki a francot érdekel ez egy desktopon? Ingo tesztjei őt minősítik nem a bfs-t - nem véletlenűl kérdezte meg Con hogy látott-e már desktopot. Arról nem is szólva hogy képtelen volt kihallani az iróniát a Con féle kommentből (ti. 16 processzoron roszabbul teljesít) és letesztelte mint egy "light NUMA" servert.

Ingo tesztjére amúgy szerintem ez a legjobb komment

> Kipróbáltam, _sokkal_ gyorsabban reagál az ilyenekre mint régen.
> Ezért is vicces hogy Ingo olyan bechmarkot hoz fel példaként hogy

Ingo olyan benchmarkot hoz fel, amilyen van neki. Desktop benchmark-ja pedig nincs. Remélem felbosszantott pár embert annyira, hogy írjanak ilyeneket is. Például nem ártana tudni (vs. érezni), hogy mi áll a "jó" desktop reagálás útjában, hogy mi a "szűk keresztmetszet".

> a make -j16 jobban teljesít cfs alatt mint bfs alatt. Ki a francot érdekel ez egy desktopon?

Jogos, de problémás. Ahogy látom jelenleg a BFS-t azért mondják deszktopra valónak, mert bár minden szerver benchmark-ot "rosszul" teljesít, de "érzésre" jobb. Mint valami placebo gyógyszer. A beteg javul, de nem tudni mitől. Így persze javítani se lehet rajta, meg eldönteni se, hogy elég jó-e a szerepére vagy egy másik deszktop ütemező jobb lenne. Én nehezen fogadom el, hogy egy "jó" deszktop ütemezőnek minden szerver benchmark-ban rosszul kell teljesítenie.

Lehet Ingó stílusát kifogásolni, de ha ez azt eredményezi hogy némiképp egzakt alapokra kerül a deszktop ütemezők megítélése (érzésre jobb vs. mérésre jobb), azzal szerintem jól járunk.

>Ingo olyan benchmarkot hoz fel, amilyen van neki. Desktop
>benchmark-ja pedig nincs. Remélem felbosszantott pár embert annyira,
>hogy írjanak ilyeneket is. Például nem ártana tudni (vs. érezni),
>hogy mi áll a "jó" desktop reagálás útjában, hogy mi a "szűk
>keresztmetszet".

Teljesen egyetértek. Az egyik kommentben valaki azt írta hogy compositing alatt az mplayer kevesebb frame-t dobott el mint cfs alatt, ez pl lehetne objektív teszt.

Szerintem akkor mondod egy desktopra hogy hű-de-gyors ha arra reagál gyorsan ami "fókuszban van". Az biztos hogy nem jó desktop ütemező aminél lényegesen többet kell várni hogy elinduljon valami ha pl másolsz valamit a háttérben.
A server féle tesztekkel az baj hogy nem érdekel hogy a háttérben a make -j2 lassaban fut-e le ha közben youtube-ot nézek és az akadozik (persze serveren pont fordított lenne a preferencia; pont hogy az a jó hogy ha egy kérést lassaban teljesít mert az nehéz, közben mások könyebb kéréséből többet kiszolgál).

Várom az ötleteket hogy mivel lehetne a "desktop élményt" jól lemérni.

> többet kell várni hogy elinduljon valami ha pl másolsz valamit a háttérben.
> nem érdekel hogy a háttérben a make -j2 lassaban fut-e le ha közben youtube-ot nézek és az akadozik

Erről nekem az ionice jut az eszembe:

- "A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period. The impact of idle io processes on normal system activity should be zero."

- "The RT scheduling class is given first access to the disk, regardless of what else is going on in the system."

Én nem vagyok biztos abban, hogy egy teljesen új desktop-only ütemező az egyedüli jó ötlet. Szerintem az is egy lehetőség, hogy egyszerűen csak adjunk a kernelnek több infót a döntésekhez, pld prioritások beállításával.

Ingóval az a gond, hogy nem azt mérte, amit kellett volna. Sőt, bele sem gondolt,
hogy mit kellene mérnie, vette a saját kis tesztjeit, lefuttatta őket, és az alapján
kritizált. Nem a kritizálás önmagában a gond, hanem az, hogy látványosan nem fogta
fel, hogy mi a probléma.

Viszont abban egyetértek, hogy ki kell teszteket találni arra a célra,
hogy a "desktop élményt" lehessen mérni. (másolás közbeni framedrop, stb.)

> Desktopon - nekem - fontosabb az hogy ha rábökök egy ikonra akkor azonnal történik valami, de egy kicsit később fejeződik be a másolás

Erről jutott eszembe: sok évvel ezelőtt azzal keresett meg az egyik kollégám, hogy a clipper programja egy helyen nagyon lassú, a felhasználók mindig megijednek hogy lefagyott a gép, mert a képernyőn percekig nem történik semmi.

Arra jutottunk, hogy kell a programba egy "progress bar". Beépítette, és a felhasználói elégedettség helyreállt. A program futásideje pedig a többszörösére nőtt, mert a "progress bar"-t rekordonként újra és újra kiírta a képernyőre.

A kód az persze nem maradt így, de azért gondolom látszik a probléma: szakmailag megfelelő megoldás-e, ha egyedül a felhasználó elégedettségét vesszük figyelembe? Van amikor nem elég, és még dolgozni kell a megoldáson.

Mielott mast lehulyezel, nezd meg mar legyszi ezt a linket:
http://hup.hu/cikkek/20090907/bfs_vs_a_mainline_kernel_utemezoje#commen…

Abban azert megegyezhetunk hogy Con Kolivas olyan utemezot irt ami a sajat gepen tuti jobban teljesit mint a kernelben levo alap utemezo. Kulonben mi a francnak irta volna?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ahogy végigolvastam a listát, nekem az jött le, hogy a lag-ban teljesít jobban a BFS,
tehát nyugodtan lehet mondjuk másolni, meg beindulhat a víruskereső, és nem fog
használhatatlanul akadozni az éppen futó alkalmazás.

Ami teszteket Ingo csinált, azok egyértelműen szerver tesztek, nem ebben jobb BFS a CFS-nél.

Ahogy feltette a kérdést valamelyik srác, mit akar a felhasználó a desktop rendszerén?
Vajon számít az, hogy egy kernel fordítás mennyi idő alatt fut le? Nem igazán. Viszont
azt elvárja, hogy a rendszer azonnal reagáljon, ha indít egy programot, akkor ne fagyjon
be az éppen futó alkalmazás, stb.

Ingo egója ingatag,
Con lelkesedése konstans ;)

Amúgy desktop ütemező. Desktop tesztek eléggé szubjektívak, szóval hajrá. Lehet tesztelni.
**szerk, dolgok keverése**
Nem tökmindegy mit drámáznak?

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

( khiraly | 2009. 09. 07., h – 17:51 )

> ha úgy adódik a jó ötleteket és kódokat átemelik a
> mainline kernelbe.

Ez a legjobb az egeszben;) Te csak fejlessz nyugodtan az egesz munkad soha a budos eletbe nem kerul bele, de ha valahol nagyon kilog a lolab, akkor majd csipegetunk belole;)

Magyarra leforditva: elhuzhatsz a p*csaba az 5leteiddel...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Erről van valami hivatalosnak tekinthető infód? Engem érdekel az, hogy a regressziót hogyan kezelik. Nap mint nap részem van benne és érdekelne egy folyamat, hogy mi hogyan történik és milyen számok vannak. Köszi!

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Regressziókról ezt találtam:

25000-30000 changesets

2-3 releases with 30-70 regressions per release, more than half of which get fixed before the next release

2.6.31-rc5 has 76 regressions, 28 unsolved as of Aug 10

2.6.30 still has 39 unresolved regressions

2.6.31 will probably have some regressions from 2.6.30, 2.6.29 and even 2.6.28

Az a vicc, hogy pedig Hungernek, meg NagyZ-nek van igaza, csak ezt te nem akarod észrevenni :))
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( khiraly | 2009. 09. 07., h – 17:59 )

Tessek, itt egy beagyazott rendszeren levo teszt:
http://marc.info/?l=linux-kernel&m=125233663823328&w=2

Magyaran BFS 1.5* jobb a CFS-nel.

De persze lehet bohockodni 64 magos geppel, hogy bizony a CFS jobb, dehat ez mar csak erolkodes;)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( krychek | 2009. 09. 07., h – 18:11 )

Ha mégis úgy döntenek, hogy lecserélik a CFS-t BFS-re, akkor azért csak meg kéne változtatni a nevét, nem?

( tompos v | 2009. 09. 07., h – 18:18 )

Az egeszben a legdurvabb info:

"Smartphones will probably start using ARM dualcore cpus the next year,
the embedded land is no SMP-free."

Wow. Mi a francnak?

tompos

Jó a marketinggépezet. Igazából az van inkább, hogy tervezési költségekben egy nagyságrend különbség van egy új, 2x gyorsabb mag és egy kétmagos CPU között.

BTW beágyazott rendszerekben gyakori hogy minden egyes magon fut egy kernel, van, hogy más oprendszer fut az egyik magon, mint a másikon.

"Jó a marketinggépezet."

Annak semmi köze a marketinghez, hogy ugyanolyan mikroarchitektúrájú de különböző órajelű processzorok fogyasztása hogyan alakul az órajel függvényében. Már akkor is láttuk, amikor a többmagos processzorok még a roadmapeken se voltak.

"Igazából az van inkább, hogy tervezési költségekben egy nagyságrend különbség van egy új, 2x gyorsabb mag és egy kétmagos CPU között."

Ez nem "igazából az van inkább", hanem "ráadásul".

( uid_228 | 2009. 09. 08., k – 09:08 )

Con Kolivas vs. Molnár Ingó e-pénisz-verseny, makk-makk^Wfej-fej mellett.

És mi van azokkal, akiket ez a szánalmas vergődés nem érdekel, csak szeretnék használni a gépüket? :) Ja, értem, vegyek Macet, én kérek elnézést, csöndben maradok ezentúl, le is ülök. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

mert egyre több az elektromos csellentyűcske a default debianban és egyre nagyobb a valószínűsége, hogy valamit nagyon benéznek. és legyen kéznél helyette valami.

most agyalnak azon, hogy a szokásos sysv initet esemény alapú indítórendszerre cserélik. igen komoly összegekkel merek rá fogadni, hogy az első stable kiadás is erősen dadogni fog, és félek tőle, hogy nem egyhamar lesz készen. ha meg készen lesz, olyan dolgokat fog tudni, amire egy szerveren semmi szükség.

( gabrielakos v | 2009. 09. 08., k – 12:23 )

Ingoban csalodtam, kulonosen a frissites altal mutatott e-mailt elolvasva.
--
Gabriel Akos

( _ventura_ v | 2009. 09. 08., k – 19:51 )

Vajon laptopokra is érdemes felrakni ? úgyértem az aksiidő nem csökken drasztikusan ?

frissítve: nyahh kb 4W al többet eszik a powertop szerint, gondolom a tickless miatt, mivel a mostani kernelem is HZ=1000 meg CONFIG_PREEMPT=y.

Core2Duo T7100, 4G, Ubuntu 9.04, 2.6.31-rc5

( Lory | 2009. 09. 14., h – 21:50 )

Phoronix letesztelte a cuccot. Összefoglalva: általában jobb mint a CFS kivéve a diskműveleteknél.

> Phoronix letesztelte a cuccot.

Hoppá:

The biggest performance boost we encountered when testing out the Brain Fuck Scheduler occurred when carrying out static web-page serving performance via the Apache web server. The number of requests per second that could be sustained was 3140 with BFS and 1902 with CFS, or a 65% boost in performance.