cfq + io prioritások

Kernel

Jens Axboe - a SuSE kernelhackere - nice szinteket épített a CFQ (completely fair queueing) IO ütemezőbe (a CFQ IO schedulerre az jellemző, hogy működése során megpróbálja egyenlő részre felosztani a rendelkezésre álló IO sávszélességet a processzek között). Hogy működnek ezek az nice szintek?

A processzhez hozzá van rendelve egy nice szint, amely a 0-tól 20-ig levő tartományban bármennyi lehet. A 0-ás és a 20-as szintek különleges szintek. A 0-ás szint jelentése: csak akkor engedélyezzük a processz számára az IO műveletet, ha a diszk ``idle'' állapotban van, a 20 jelentése: a processz IO-ját valósidejűnek (realtime) tekintjük. A valósidejű IO-val rendelkező processz fér hozzá a diszkhez elsőként. Az 1-19 szint valahol a kettő között van, azaz az IO 5%-95%-át ``engedélyezi'' a processz számára.

Mire is jó ez?Gondoljuk bele abba a helyzetbe, hogy CD-t írunk, és közben a háttérben olyan feladat fut, mint a sok diszk művelettel járó ``updatedb''. Ebben az esetben megadhatjuk, hogy a ``cdrecord'' 20-as szinten fusson valósidőben, míg az ``updatedb'' a 0-son. Ezzel biztosítjuk, hogy az írás szempontjából kritikus művelet magasabb prioritást kapjon, mint a kevésbé fontos frissítési művelet.

Mivel tudjuk a nice szinteket állítani? Jens készített egy user-space eszközt a feladat ellátására. A neve ``ionice''. Használata:

# ionice -n20 bash

Ez azt jelenti, hogy a bash valósidőben fut. A használat során figyelembe kell venni, hogy a nice szint öröklődik a fork során, így az összes ebből a shellből indított program valósidőben fog futni.

# ionice -n0 dbench 32

Ezzel a paranccsal 0-ás szinten futtatjuk a ``dbench'' nevű programot, amely kizárólag akkor fog csak futni, ha a diszk éppen idle állapotban van.

Az új processzek számára alapértelmezett IO nice szint 10.

Jens Axboe levele, patch, magyarázat itt.

( Névtelen (nem ellenőrzött) | 2003. 11. 12., sze – 10:43 )

Huuu bazzeg befiorgat meg csinaltam ....

Lass csodat fel se bootol a gep :((((((((((((

( fellow | 2003. 11. 12., sze – 23:26 )

miért pont 0-20? a niceban meg van az a logika, hogy a user is szabalyozhatja, de nem férhet hozzá a negatív értékekhez;

a patch a legutolso -BK kernelhez keszult, nem a default IO utemezohoz (a default az anticipatory IO scheduler). ezek a patchek tulkeppen eloszor csak fejlesztoi gepeken futnak, es proof-of-concept jelleguek, azaz egy teoria alatamasztasat vagy elveteset celozzak. Ha az elkepzeles jo, akkor szvsz. megvalositjak komolyabb hozzaferes szabalyozassal is, ha nem akkor elvetik. Jelenleg a teszeles szakaszban van a dolog, ahogy neztem sokan orulnek az elkepzelesnek.

http://members.optusnet.com.au/ckolivas/kernel/

termeszetesen itt a hupon hallottam rola eloszor (https://portal.fsn.hu/modules.php?name=News&file=article&sid=3527)

elotte ugy probaltam "oldani a feszultseget", hogy +18 -as nice szinten inditottam a mervelmezt erosen igenybevevo dolgokat; ez egy cp / mv eseten bevalt, de az apt melletti mplayer-ezes mar szaggatott;