Molnár Ingo: O(1) scheduler, akár 187% -os teljesítmény növekedés?

Linux

Idén január 4-én Molnár Ingo az LKML-re postázott egy levelet, amelyben bejelentette, hogy egy új Linux ütemezőn dolgozik.
Az új scheduler akár 18-187% százalékos növekedést jelenthet a Linux kernel teljesítményében, bizonyos esetekben (láttam olyan benchmarkot, ahol 300% -os növekedés volt realizálható).

Ahogy Ingo levélben írja, ez a jelenlegi Linux ütemező radikális átirata lesz.

A projekt célja, hogy megtartson minden olyan tulajdonságot a jelenlegi scheduler-ből, ami használható:

- jó interaktív teljesítmény: ha a felhasználó gépel, vagy klikkel a rendszer válaszoljon szépen, futtassa a felhasználó task-ját
- prioritás: a kevésbé fontos feladatok fussanak (induláskor) kisebb prioritással, a fontosabbak nagyobb prioritással induljanak
- SMP hatékonyság: ne pihenjen a CPU, ha lenne mit tennie (gondolom a második vagy n-edik CPU -ról van szó)
- SMP affinitás: ha a processz elindult egyik CPU-n, lehetőleg a továbbiakban is fusson azon a CPU-n, ne váltogasson a CPU-k között túl gyakran
- plusz további szolgáltatások kerüljenek bele, mint például az RT scheduling, CPU-hoz kötésEzenkívül kerüljön bele új funkció is:

- teljes O(1) ütemezés
- 'tökéletes' SMP skálázhatóság
- jobb SMP affinitás
- kötegelt (batch) scheduling
- kezelje az extrém magas load-okat jobban, összeomlás és scheduling storm nélkül
- O(1) RT scheduling
- futtassa a fork()-olt "gyermek" (childer) processzt a "szülő" (parent) processz előtt

A patch letölthető innen.

Tulajdonképpen ez a lényege a Mingo O(1) scheduler patch-eknek. Jó hír, hogy Linus a 2.5.2-pre10 óta beletette a 2.5-ös devel kernelbe az új ütemezőt. Közben jöttek sorban a patchek, és Robert Love bejelentette, hogy a preemptive kernelpatch kompatibilis lett Molnár Ingo új ütemezőjével. Tehát akár együtt is használhatjuk őket.

Szóval ez mind szép és jó, de miért is jó ez nekünk? Miért jobb az új scheduler, mint a régi?

Partha Narayanan az IBM-től, készített egy friss teljesítménytesztet Ingó O(1) ütemezőjével. A teszt egy 8-utas 700Mhz-es Pentium III szerveren futott, különböző beállításokkal. A teszteket úgy végezték, hogy csak egy CPU volt engedélyezve, aztán 4 CPU, és végül mind a 8 CPU használatban volt.

Az összes tesztet a 2.4.17-es kernelen végezték, összehasonlítva a régi scheduler-t a legfrissebb új O(1) scheduler-el, ami a teszt pillanatában a -J2 -es volt. (A postázás pillanatában már elérhető volt a -J4 -es is)

Az eredmények meggyőzőek az új scheduler-el. A tesztek azt mutatták, hogy a teljesítmény kb. 18%-al javult egy CPU esetén, kb. 45%-al javult 4 CPU -val, és kb. 187% !!! javult a teljesítmény 8 CPU-val. Természetesen a régi ütemezőhöz képest. IMHO nem rossz.

A teszteléshez a Java alapú ValanoMark-ot használták.

( trey | 2002. 01. 25., p – 21:34 )

Biztatasul:

Este megkerdeztem a #kernelnewbies csatornan az ottani community velemenyet a patch -rol:

|trey| what is this community opinition about mingo's (0)1 scheduler? in nutshell?
--> cHuKy (~chuky@193-153-23-8.uc.nombres.ttd.es) has joined #kernelnewbies
--> pragimus (~pragma@adsl-64-169-2-246.dsl.renocs.nvbell.net) has joined #kernelnewbies
|velco| scatter-gather is good for _unrelated_ frames too, e.g. you can setup SG receive DMA and receive a bunch of frame with a single interrupt.
|badd00d| trey: loving it.
|riel| trey: it rules
|crimsun| trey: by no means do I speak for the community, but I like it.
|oxymoron| trey: Seems good.
|velco| trey: it rocks.
|trey| thx
|trey| i try it
|negrox| under which menu in the kernel config is the devfs stuff? (I did look)
sarnold| trey: I'm too conservative to have tried it yet :)

Azt hiszem nem rossz velemenyek. Foleg nem, ha olyan hackerek mondjak, mint riel (Rik van Riel).

Yep. Hasznalom az uj scheduler -t kb. ket hete, tegnap letoltottem a legfrissebb verziot (-J7 asszem) és a 2.4.17 -et patcheltem meg vele. Leforgat, reboot. Miutan ujrabootoltam, mar latszott, hogy valami nem ugyanaz. Az X gyorsabban indult, az ablakok gyorsabban bejottek, az opera szinten gyorsabban indult. Lehet, hogy csak bemagyaraztam magamnak? A CPU terheles kisebb lett, ezt viszont a gkrellm egyertelmuen mutatta. Viszont hasznalok a gepemben tvtuner kartyat, es amikor az xawtv -n hangot allitottam a regi kernellel, akkor az kicsit keslekedve valaszolt. Viszont a mingo patch -el a reakcioja sokkal gyorsabb lett. Nem csak en probaltam ki, hanem Friczy baratom is, o is ezekrol a megfigyelesekrol szamolt be. Szamszeruleg nem tudom pontosan, hogy mekkora a rendszer gyorsulasa, mert olyan programot amivel ezt merhettem volna, meg nem talatam, de szerintem az egy CPU -val valo 18-20% gyorsulas az realis lehet. Termeszetesen tobb CPU -val a gyorsulas a meresek szerint drasztikusan megno. IMHO erdemes kiprobalni a stuff -ot, mert valoban jo.

Hello.
Kosz a valaszt. Meg hezitalok kicsit, hogy hasznaljam, mert meg nem vagyok egy nagy asz linuxban, de lelkes vagyok.
Okoz valami nehezseget a felrakasa?

A kernelhackeres cikkhez csak annyit, hogy jo es erdekes. Es az aki a helyesirasi tartalmat veszi elobb eszre, mint a tartalmat, szerintem nem igazan fogta fel a lenyeget.

Udv.

Hat igen buzgo nyelvorok mindig is voltak/lesznek, de ez igy van jol. En legkozelebb igyekszek helyesebben irni, ok meg kicsit toleransabbak lesznek. Ha nem, az se baj =).

Lassuk, mit is kell tudni a kernelpatch -ek hasznalatarol:

Altalaban a patch -ek valamilyen compressed formaban vannak (.gz, ujabban .bz2)

tehat letoltjuk a kernelpatch -et, kibontjuk a kernelforrast, amelyet elozoleg letoltottunk valamelyik mirror -rol.

A kernelforras helye altalaban a /usr/src/linux
A patch -et masoljuk bele ebbe a konyvtarba, malyd adjuk ki a kovetkezo parancsot:

gzip -cd patchXX.gz | patch -p1

vagy ha .bz2 -ben van, akkor:

bzip2 -dc patchXX.bz2 | patch -p1

Jelen esetben ez igy nez ki:
root@sunshine:/data/kernel/linux# ls sched-O1-2.4.17-J7.patch.gz

sched-O1-2.4.17-J7.patch.gz

root@sunshine:/data/kernel/linux# gzip -cd sched-O1-2.4.17-J7.patch.gz | patch -p1
patching file fs/proc/proc_misc.c
patching file fs/proc/array.c
patching file fs/nfs/pagelist.c
patching file fs/ufs/truncate.c
patching file fs/reiserfs/buffer2.c
patching file fs/reiserfs/journal.c
patching file fs/jffs2/background.c
patching file fs/jbd/journal.c
patching file fs/jbd/revoke.c
patching file fs/jbd/transaction.c
patching file fs/binfmt_elf.c
patching file fs/buffer.c
patching file fs/locks.c
patching file init/main.c
patching file kernel/sched.c
patching file kernel/exit.c
patching file kernel/capability.c
patching file kernel/timer.c
patching file kernel/fork.c
patching file kernel/softirq.c
patching file kernel/ptrace.c
patching file kernel/sys.c
patching file kernel/signal.c
patching file kernel/printk.c
patching file kernel/ksyms.c
patching file mm/oom_kill.c
patching file mm/page_alloc.c
patching file mm/highmem.c
patching file include/linux/sched.h
patching file include/linux/list.h
patching file include/linux/kernel_stat.h
patching file include/linux/smp.h
patching file include/asm-i386/smp.h
patching file include/asm-i386/bitops.h
patching file include/asm-i386/pgalloc.h
patching file include/asm-i386/mmu_context.h
patching file include/asm-i386/hw_irq.h
patching file net/unix/af_unix.c
patching file net/ipv4/tcp_output.c
patching file net/sunrpc/sched.c
patching file net/sched/sch_generic.c
patching file net/socket.c
patching file drivers/net/slip.c
patching file drivers/block/loop.c
patching file drivers/char/mwave/mwavedd.c
patching file drivers/ide/ataraid.c
patching file drivers/md/md.c
patching file arch/i386/mm/fault.c
patching file arch/i386/kernel/smpboot.c
patching file arch/i386/kernel/process.c
patching file arch/i386/kernel/apic.c
patching file arch/i386/kernel/nmi.c
patching file arch/i386/kernel/smp.c
patching file arch/i386/kernel/i8259.c
patching file arch/i386/kernel/entry.S
root@sunshine:/data/kernel/linux#

Ennyi. Utanna szokasos modon leforgatjuk a kernelt, es ujrabootolunk a patch -elt kernellel. Mindig hasznaljunk eredeti kernelforrast, vagy ugyeljunk arra, hogy ha mar hasznaltunk valamilyen patch -et, akkor az mukodjon egyutt a jelenlegivel. Kulonben forditasi problemakat kaphatunk.

Meg annyit a patch -eleshez, mert latom sokakanak okozott gondot (legalabbis a kapott levelek alapjan gondolom ;)) :

miutan a fennt emlitett modon a kernelt megpatch -eltuk, rendesen ujra kell forditani a kernelunket.

Tehat:

Ha kiirta, hogy patching egy csomo file ra, es kozben nem irta ki hogy reject (es nem keletkeztek .rej filek), es utanna visszakaptad a prompt -ot , akkor jo a patcheles.

Ha ez megvan, utana:

szokasos modon configuralod a kernelt, (ha ezt elotte meg nem tetted volna meg).

Tehat:

make menuconfig ( a scheduler nem igenyel beallitast, nem is lehet allitani, mivel nem szolgaltatas, hanem alapfunkcio)

elmented

make dep clean bzlilo (vagy bzImage igeny szerint) modules modules_install;depmod -a

edit lilo.conf

reboot

ha mindent jol csinaltal, akkor legkozelebb mar az uj kerneled fog futni, az uj schedulerrel .

Enjoy it.

( Pontscho | 2002. 01. 28., h – 17:37 )

Ha rendesen atolvasod a cikket, kitunik, hogy serverre plane erdemes :)

Es azert kell make clean ( ami nem csak kernelnel erdemes ), hogyha valami belegazolt az src - be, akkor is korrekt legyen a forditas. De a kernelnel sem kotelezo. Max fagy.

Pontscho

Az edit lilo.conf es a reboot kozott megemlitenem, hogy 'lilo' ;D (akinek a leiras szukseges, annak ez nem egyertelmu, nekik szol)

Meg valami: szerintem a make modules_install es a depmod -a 2.4-tol folfele mar nem szukseges, a Makefile tartalmazza.

Vegul: a legjobb, ha a debian-os kernel-source-2.4.17 -tel vegezzuk el mindezt, mert az minden egyebet megcsinal, beleertve a lilo-t is.

mingo a kiraly :)

( trey | 2002. 01. 29., k – 13:02 )

A linux-flame listan kernelfejlesztok vannak? Mert ott lattam mar minden fele temat a trabant fotengelytol kezdve a hogyan epitsunk satratig. Nem hiszem, hogy mervado lenne.

En se ertek hozza ezert kerdeztem meg egyket hozzaerto embert.

Ideztem egyket aktiv fejleszto hozzaszolasat, es eddig mindenkinek csak jo velemenye volt a patch -rol. Naes az, hogy bekerult a 2.5 faba az imho eleg ok, Linus -nak konzervativabb fejlesztot nem negyon talasz (bar volt amikor racafolt erre).

Ja es ha szamit valamit a sajat tapasztalatom, akkor elmondhatom, hogy par nap teszteles utan, nekem is csak jo velemenyem van rola. Igaz, hogy par nap nem ok arra, hogy komolyabb kovetkezteteseket vonjunk le a dologbol, de itt egy _fejlesztes alatt allo dologrol_ van szo, eles szerverre semmi esetre sem ajanlatos tenni.