FreeBSD ULE Scheduler Port

Linux

Folyatódik a Linux scheduler saga. Szeptember 4-én írtam arról, hogy három ütemező implementáció "versenyez" egymással a 2.6-ba való bekerülésért. Most itt a következő jelölt. Francesco Sportolari is készített egy ütemező patchet a 2.6.0-test5 kernelhez. A patch a FreeBSD ULE ütemezőjének linuxos portja.

Francesco magyarázata:

"Az interactive_score() függvény minden processzhez kalkulál egy interaktív pontszámot. Ha a processz pontszáma kevesebb, mint az INTERACTIVE_THRESHOLD érték, akkor a processz maga interaktívnak tekinthető, és kap egy a MIN_TIMESLICE-ban meghatározott időszeletet. Az összes többi processz annyi időszeletet kap, amely arányos az effektív prioritásával."

Francesco elmondta a tesztelési tapasztalatait is:"az xmms audio-ugrás probléma megjavult, az ablak rázás teszt sikerült :)" (azt hiszem ez magyarázatra szorul :-) A fejlesztők az utóbbi időben úgy tesztelték az ütemezőt, hogy kernelt fordítottak több szálon, és közben xmms-sel audiót hallgattak. Ha az mp3 lejátszás nem "ugrott" akkor a teszt sikerült. A másik ilyen teszt az, hogy egérrel "megfogják" az ablakot a felső részénél fogva, és rázzák. Ha az ablak nem lassított felvételként mozog, akkor a test sikeres)

A patch mind PPC, mind i386 architektúrára elérhető.

A FreeBSD ULE ütemezőt egyébként Jeff Roberson készítette, és beolvasztásra került "kísérleti" jelzővel a FreeBSD 5.1-be.

Egy érdekes PDF dokumentum:

ULE: A Modern Scheduler For FreeBSD

Francesco Sportolari levele és a patch itt.

( trey | 2003. 09. 10., sze – 09:27 )

hmm, miert nem kuldesz egy patchet az elkepzelesrol? ;-) vagy legalabb egy draft-ot ami alapjan meg lehet irni. lehet ez eszukbe se jut..

( rhapsodhy | 2003. 09. 10., sze – 16:11 )

Ez lenne a legjobb kéne dobni Linusnak egy erről szóló levelet az LKML-re. Csak én nemtok eléggé angoloul:)

( opaque | 2003. 09. 10., sze – 17:46 )

Csak halkan kerdezem, hogy a "nice" mire valo?

( nice - run a program with modified scheduling priority )

Szoval a spanyolviaszt akarjuk ujra feltalalni, vagy en nem ertem, hogy mi az uj az otletedben.

Gondolom a valaszod erre, hogy az utobbi, de akkor homalyosits fel legyszives, hogy mi a kulonbseg.

( opaque | 2003. 09. 10., sze – 20:40 )

Attol aki megmagyarazza nekem :)

A kerdesem Arpi felvetesere vonatkozik. Mindenfele tovabbi fejlesztes nelkul jelenleg is megoldhato, hogy a felhasznalo, illetve az adott alkalmazas valtoztasson a futtatasi prioritasan. (nice/renice/getpriority/setpriority)(nem root eseten csak csokkentheti)

Tehat csak az kellene, hogy minden "nem-interaktiv" program megfeleloen csokkentse sajat prioritasat.

Magyaran ehhez kepest mi ujdonsagot szolgaltat Arpi elkepzelese?

Szerintem pont az a baj, hogy onkentessegi alapon nem mukodik, mert majd' minden process alapertelmezett prioritassal fut, ezert kell a kernel-nek diferencialnia koztuk.

Illetve meg az lehetne megoldas, hogy az alapertelmezett prioritasi szinthez merten, valamilyen mertekben a mezei felhasznalok/processzek novelni is tudjak a prioritasukat, ne csak lemondani rola....(de ekkor sem kellenek uj flag-ek, meg tool-ok...)