Molnár Ingo: realtime-preempt patch

 ( trey | 2005. június 11., szombat - 20:09 )

Tavaly nyáron több kritika is érte a 2.6-os Linux kernelt amiatt, hogy nem használható komolyabb audio munkára, mert borzasztóan nagy az ütemezési latency-je. Akkor Ingo elkezdett dolgozni egy voluntary kernel preemption patch-en (korábbi cikkünk), annak érdekében, hogy csökkentse ezt a latency-t.

Ingo jelenleg egy realtime-preempt nevű patchen (-RT) dolgozik. A realtime-preempt patch célja, hogy garantálja a magas prioritású felhasználótérbeli processzek válaszadási idejének maximumát, hasonlóan ahhoz, ahogy azt az igazi valós idejű operációs rendszerek (Real Time Operating System - RTOS) teszik. Ezt a célt úgy igyekszik elérni, hogy a kernelben mindent preemptívvé tesz. Nem érdekes, hogy a kernel éppen min dolgozik, ha egy magasabb prioritású processz futtatható állapotba kerül, akkor az azonnal ütemeződik.

A visszajelzések szerint az audio-val kapcsolatos Linux disztribútorok már szállítják az -RT kerneleket, és a legtöbb komolyan audio-val foglalkozó linuxos felhasználó is ezt futtatja. Több ezer ember használja 7/24-ben hónapok óta, és május közepén már ott tartottak, hogy több mint egy hónapja nem találtak benne igazi bugot.

Nézzük hogyan használhatjuk:Előszöris kernelt kell patchelnünk. A legutoljára kiadott -RT patch a realtime-preempt-2.6.12-rc6-V0.7.48-11 (megj: annak ellenére, hogy a 11 is ma jelent meg, már itt is az új verzió, a realtime-preempt-2.6.12-rc6-V0.7.48-16) a névre hallgat. Ezzel megpatchelve a kernelt, a make menuconfig-ban előtűnik egy új opció a ``Processor type and features'' alatt:

Keressük meg a ``Preemption Mode (Complete Preemption (Real-Time))'' menüpontot, majd nézzünk szét alatta...

Belépve a menübe azt láthatjuk, hogy négy lehetőség szerint állíthatjuk be a kernelünket attól függően, hogy milyen szerepet szánunk neki. Lehet:

Szerver: Nagy throughput, megfelelő latency, ami akár lehet azért nagyobb is. Szervernél nem annyira kritikus a latency, mint egy desktop esetén. Szerverekhez, tudományos munkaállomásokhoz ajánlott beállítás. Ott érdemes ezt használni, ahol a kernel nyers számítási teljesítményére van szükség.

Desktop: Romló throughput, de javuló (kisebb) latency. Az alkalmazások sokkal simábban futnak, gyorsabban reagálnak. Átlagos desktophoz ajánlott.

Alacsony latency-jű desktop: Tovább romló throughput, viszont tovább csökkenő latency. Ennek eredményeképpen nagyobb load alatt a desktop alkalmazások még szebben futnak. Olyan desktopokhoz és beágyazott rendszerekhez ajánlott, ahol a latency kívánatos értéke 1 millisec-en belül van.

Teljes preemption (Real-Time): Ez a beállítás adja a legkisebb latency-t, a legjobb reagálási képességet az alkalmazások számára terhelés alatt. Ez a beállítás olyan desktopok, beágyazott vagy valós idejű rendszerek számára ajánlott, ahol 100 usec-nél kisebb latency kívánatos.

Sokan kérték a patch beolvasztását a mainline kernelbe, de egyben sokan ellenezték is. Egy LKML tag május 23-án kérte az -RT beolvasztását. Azóta több mint 300 válasz érkezett a postra. A thread itt kezdődik (csak erős idegzetűeknek).

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

ULE hogy van? :-)

A használatakor érdemes a debug opciókat kikapcsolni a ``Kernel hacking'' menüpont alatt. Két napja fut nálam a 2.6.12-rc6 az -RT patchcsel. Teljes preemption-t (Real-Time) választottam, és valóban olyan, mintha sokkal fürgébb lenne a rendszer.

10-es loadnál (make -j 8 kernelfordítás közben) szépen scrollozódik a Firefox, megy az mp3 lejátszás, gyorsabban váltódnak az ablakok....

Persze lehet, hogy csak optikai csalódás... Akinek van kedve tesztelni megírhatná a tapasztalatait...

kivancsi lennek mekkora ez a bizonyos overload.
0.1% 1%, 10%? , csak ugy nagysagrendileg.

Hát én hackbench-el teszteltem (ütemező tesztelő). Ezeket az eredményeket kaptam:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111843713618855&w=2

Ennek ellenére kisebbnek látszik a desktop reakcióideje. De mondom, lehet, hogy csak optikai csalódás...

Lefuttattam a vm_torture [www.hup.hu] tesztet is... Az -RT patchelt kernelnekem jobb eredmenyeket hozott, mint a sima -rc6...

Nekem úgy tűnik, hogy a vmware5 kernelmoduljai nem fordulnak le vele. Ha valakinek mégis megy, az szóljon. :)
Ezt a hibaüzenetet produkálja a vmware-config.pl kernel modul fordítás közben:

make[1]: Entering directory `/usr/src/linux-2.6.12-rc6'
CC [M] /tmp/vmware-config3/vmmon-only/linux/driver.o
/tmp/vmware-config3/vmmon-only/linux/driver.c:582: error: `SPIN_LOCK_UNLOCKED' undeclared here (not in a function)
/tmp/vmware-config3/vmmon-only/linux/driver.c: In function `LinuxDriverPoll':
/tmp/vmware-config3/vmmon-only/linux/driver.c:779: error: `SPIN_LOCK_UNLOCKED' undeclared (first use in this function)

Nekem lefordulnak.

[/lib/modules/2.6.12-rc6-RT-V0.7.48-11/build/include]

Extracting the sources of the vmmon module.

Building the vmmon module.

Building for VMware Workstation 5.0.0.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vmmon-only'
make -C /lib/modules/2.6.12-rc6-RT-V0.7.48-11/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.12-rc6-mingo'
CC [M] /tmp/vmware-config0/vmmon-only/linux/driver.o
CC [M] /tmp/vmware-config0/vmmon-only/linux/hostif.o
CC [M] /tmp/vmware-config0/vmmon-only/common/cpuid.o
CC [M] /tmp/vmware-config0/vmmon-only/common/hash.o
CC [M] /tmp/vmware-config0/vmmon-only/common/memtrack.o
CC [M] /tmp/vmware-config0/vmmon-only/common/phystrack.o
CC [M] /tmp/vmware-config0/vmmon-only/common/task.o
cc1plus: warning: "-ffreestanding" is valid for C/ObjC but not for C++
CC [M] /tmp/vmware-config0/vmmon-only/common/vmx86.o
CC [M] /tmp/vmware-config0/vmmon-only/vmcore/compat.o
CC [M] /tmp/vmware-config0/vmmon-only/vmcore/moduleloop.o
LD [M] /tmp/vmware-config0/vmmon-only/vmmon.o
Building modules, stage 2.
MODPOST
CC /tmp/vmware-config0/vmmon-only/vmmon.mod.o
LD [M] /tmp/vmware-config0/vmmon-only/vmmon.ko
make[1]: Leaving directory `/usr/src/linux-2.6.12-rc6-mingo'
cp -f vmmon.ko ./../vmmon.o
make: Leaving directory `/tmp/vmware-config0/vmmon-only'
The module loads perfectly in the running kernel.

You have already setup networking.

Would you like to skip networking setup and keep your old settings as they are?
(yes/no) [yes]

Extracting the sources of the vmnet module.

Building the vmnet module.

Building for VMware Workstation 5.0.0.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vmnet-only'
make -C /lib/modules/2.6.12-rc6-RT-V0.7.48-11/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.12-rc6-mingo'
CC [M] /tmp/vmware-config0/vmnet-only/driver.o
CC [M] /tmp/vmware-config0/vmnet-only/hub.o
CC [M] /tmp/vmware-config0/vmnet-only/userif.o
CC [M] /tmp/vmware-config0/vmnet-only/netif.o
CC [M] /tmp/vmware-config0/vmnet-only/bridge.o
CC [M] /tmp/vmware-config0/vmnet-only/procfs.o
LD [M] /tmp/vmware-config0/vmnet-only/vmnet.o
Building modules, stage 2.
MODPOST
CC /tmp/vmware-config0/vmnet-only/vmnet.mod.o
LD [M] /tmp/vmware-config0/vmnet-only/vmnet.ko
make[1]: Leaving directory `/usr/src/linux-2.6.12-rc6-mingo'
cp -f vmnet.ko ./../vmnet.o
make: Leaving directory `/tmp/vmware-config0/vmnet-only'
The module loads perfectly in the running kernel.

Starting VMware services:
Virtual machine monitor done
Virtual ethernet done
Bridged networking on /dev/vmnet0 done
Host-only networking on /dev/vmnet1 (background) done
Host-only networking on /dev/vmnet2 (background) done

The configuration of VMware Workstation 5.0.0 build-13124 for Linux for this
running kernel completed successfully.

You can now run VMware Workstation by invoking the following command:
"/usr/bin/vmware".

Enjoy,

--the VMware team

Probald meg a vmware-any-any-update91.tar.gz [ftp.cvut.cz] patchet feltenni. Az uj kernelekhez kell!

Hm, igazad van. A -11-gyel meg lefordulnak, de felette mar nem. A 13-mal nekem is ugyanez a hiba.

Jó tudni, hogy a 11-gyel mennek.
Próbáltam sufnimódszerrel kijavítani a vmware-es kernelmodulok forrását, aszerint, ahogy az RT patchben van. Nem vezetett túlzott sikerre, mert bár a modulok lefordultak, nagy lockup-ok voltak a jutalmaim érte. :)

Most, hogy fordítottam RT patch nélkül egy kernelt, még mindig vannak lockupok, tehát lehet, hogy mást szúrtam el a 2.6.11.8 -> 2.6.12-rc6 átállásnál és talán ez az átírós módszer alapvetően jó ötlet volt.

Ezalapján próbáltam meg átírni a modulok forrását (driver.c a vmmon.tar-ban és hub.c a vmnet.tar-ban):

--- linux/net/core/pktgen.c.orig
+++ linux/net/core/pktgen.c
@@ -503,7 +503,7 @@ static int pg_delay_d = 0;
static int pg_clone_skb_d = 0;
static int debug = 0;

-static spinlock_t _thread_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(_thread_lock);
static struct pktgen_thread *pktgen_threads = NULL;

static char module_fname[128];

Igen, ez az előző patch részlet a 12-ssel került bele, sok egyéb hasonló átalakítással. Ezért megy még a 11-es.

Zumi

Hm. Page Not Found 404. :(

Sz.

Ez azt jelenti, hogy Mingo mar ki is adta a kovetkezo verziot :-) naponta 3-4 revizio is megjelenik...

Itt az uj:

http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.12-rc6-V0.7.48-16

A még újabb [people.redhat.com]

A sima desktop gépemen (ami egy laptop) van értelme ezt használni? El fogok tőle ájulni?
Mivel csak egy 700/1000MHz-es PIII-asom van, minden gyorsítószert szívesen veszek.

Jelenleg a Con Kolivas-féle foltozott Linux kernelt használom Gentoo-val, arról is azt mondják, hogy *****ább, de nem igazán tudom megítélni, összehasonlítani, inkább elhiszem.
http://members.optusnet.com.au/ckolivas/kernel/ [members.optusnet.com.au]

Ugyan nem akarok audiót feldolgozni, de azért kíváncsi vagyok.
Köszi minden kommentet!

Jha, kell is. A 16 csontkeményre fagyasztotta a kernelt. Meg a Magic Sysrq-ra se reagalt.

Fura. Nálam simán megy 5 órája.

Sz.

Melyik preemption mode-dal?

A 17 megy nekem is mar 1 ora 40 perce.

Nekem a 17 fagyasztotta 3x szét a gépet, úgyhogy kicsit morc lettem.

Polonkai Péter wrote:
> Nekem a 17 fagyasztotta 3x szét a gépet, úgyhogy kicsit morc lettem.

Khmm...

>> Több ezer ember használja 7/24-ben hónapok óta, és május közepén
>> már ott tartottak, hogy több mint egy hónapja nem találtak benne
>> igazi bugot.

A lockup micsoda, ha nem bug? :-)

Real-time. De aztán jöttek a fura dolgok.
Valami megzabálta az összes memóriát. Nemtom hogy ez az rc6 vagy az RT "jótékony hatása". Meg leállításkor voltak még fura dolgok. :(

Asszem én még várok vele egy kicsit.

Sz.

Jah, nekem is. Szoval meg eros lenne ez merge-lésre.

linuxban csak az szamit bugnak ha kapasbol rootra lehet torni vele a rencert

de abbol is osszevarnak 2-3at hogy ne kelljen annyi javitast kiadni