Molnár Ingo: Voluntary Kernel Preemption Patch

 ( trey | 2004. július 10., szombat - 12:02 )

A tuning mester Molnár Ingo küldött egy levelet az LKML-re, amelyben egy új patch-ről számol be.
Mint írja, többen is szóvá tették a listán, hogy a 2.6-os Linux kernel nem használható komolyabb audio munkákra, mert borzasztóan nagy az ütemezési latency-je (például a JackIt fejlesztők is reklamáltak emiatt).
Ingo megnézte a 2.6.7-es kernel latency-jét, és azt tapasztalta, hogy valóban rossz. A latency akár 50 msec (!) is lehet, amely simán reprodukálható normális terhelés mellett egy olyan gyors 2GHz+ x86 rendszeren is, amely teljesen preemptive kernelt futtat.

Ezért Ingo és Arjan van de Ven végigmentek a kernel különböző funkcióin és megvizsgálták azok latency-jét. A munka eredményeképpen megszületett egy patch, amely teljesen 0-ról íródott, teljesítményben egyenlő a korábbi 2.4-es kernelhez készült lowlatency patchek teljesítményével, de más dizájnnal rendelkezik, mások a hatásai és más megközelítésből ered.A lowlatency patch-csel ellentétben ez a patch nem ad új ütemezési pontokat a kernel forráshoz, hanem a már meglevő gazdag választékból használja fel azokat, amelyek nem voltak eddig használatban. A patch célja, hogy eltávolítson minden olyan latency forrást, amely nagyobb, mint ~1 msec latency-t generálna a rendszerben. A tesztek során a patch felhasználása mellett a fejlesztők próbáltak olyan terhelést generálni a teszt rendszeren, amely audio ``ugráshoz'' vezetett volna, de nem tudtak olyan workload-ot generálni, hogy a latency ~1 msec fölé elmelkedett volna.

A patch magasabb szinten konfigurálható, mint a 2.4-es lowlatency patch. Van egy .config opció (CONFIG_VOLUNTARY_PREEMPT), amellyel engedélyezni lehet a voluntary preemption-t, emelett van /proc/sys kapcsoló és boot-idejű paraméterezési lehetőség is.

# A voluntary preemption be/ki kapcsolása (ha a CONFIG_VOLUNTARY_PREEMPT kernelben van)
echo 1 > /proc/sys/kernel/voluntary_preemption
echo 0 > /proc/sys/kernel/voluntary_preemption

# preemptible kernel funkció be/ki kapcsolása (ha a CONFIG_PREEMPT a kernelben van)
echo 1 > /proc/sys/kernel/kernel_preemption
echo 0 > /proc/sys/kernel/kernel_preemption

Boot-idejű opciók:

'voluntary-preemption=0/1' és 'kernel-preemption=0/1'

A patch a 2.6.7-bk20 kernelhez készült, és több olyan hibát is fixál, amelyet a készítők a fejlesztés közben találtak. A patch működik a fejlesztőknek (tm), de óvatosan használja mindenki! A szerzők minden visszajelzést szívesen fogadnak.

Bővebben Ingo levelében és a thread-ben itt.



A patch letölthető:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H3



Aki a vanilla 2.6.7 kernelen szeretné kipróbálni a patchet, az töltse le ezt:

http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-vanilla-H3

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Komolyabb audio munkákra ezért használnak célhardvereket és legvégső esetben is csak MacOS-t. :) Egyébként örülök neki, hogy ilyen jól halad a Linux fejlesztése, szóval nehogy valaki ezt a hozzászólásomat flamenek vegye...

Pár órája használom, tényleg gyorsabb reakcióidőket érzek. Hozzá kell tennem, éppen átálltam 2.6-os Gnome-ról 2.7-esre, Mozilla helyett Firefox-ra, stb. Ezek is befolyásolhatják az összképet, de biztos hogy 85 Mb-nyi frissités feltétele közben nem bicsaklott meg a 320 kb/s mp3, igaz NFS-ről jön...

A Java-m meg elhalt, feltételezem a patch miatt. :(

nem hiszem, mert nekem tokeletesen mukodik a Java. hanyas Java VM-et hasznalsz?

Ez most proci-, vagy I/O-ütemező? Nem arról volt szó régebben, hogy Ingó csodás O(1) ütemezője minden problémát megold(ott)? :)

Egyik sem. A kernelben egy csomo helyen debug infokent jelezve
van hogy hol sleepelhet, ezeket hasznaltak fel mint scheduling
entry pointok (plusz meg kerestek egy nehany masikat). Ezert
voluntary, mint a regi szep w31-es idokben :)

AA persze kritizal, mingo visszavicsorit, MM meg biztos azt
mondja majd hogy "looks good just wait a moment until things
calm down a bit..."

A legújabb stabil SUN-osat, 1.4.2, patchlevel 3-as ha jól emlékszem. Neked milyen JVM/J2SDK-ád van?

> AA persze kritizal, mingo visszavicsorit, MM meg biztos azt
mondja majd hogy "looks good just wait a moment until things
calm down a bit..."
... és így van jól, márcsak a tesztelés miatt is, az időbe telik. A többit meg eldönti az élet.

(1.2GHz 52C) trey@alderaan:~ $ /usr/local/j2re1.4.2_03/bin/java -version
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

és

(1.2GHz 52C) trey@alderaan:~ $ /usr/local/java/bin/java -version
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)

Mindegyikkel csont nélkül működik.

Közben én is teszteltem, vanilla kernellel is ue történik, vagyis nem a patch hibája.
Már csak egy kérdésem maradt: Sarge vagy Sid? Nekem Sid, némi experimental-lal vegyítve a 2.7-es Gnome végett.

Sarge, mai frissitessel.