Molnár Ingo: realtime-preempt patch

Kernel

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

( trey | 2005. 06. 11., szo – 20:18 )

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

( selli | 2005. 06. 11., szo – 21:50 )

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

( adarazs | 2005. 06. 12., v – 02:36 )

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!

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];

( mindegy v | 2005. 06. 12., v – 19:59 )

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!

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? :-)