Javaslat az alapértelmezett I/O ütemező CFQ-ról deadline-ra való megváltoztatására

Kernel

Napjaink mainline Linux kerneleinek alapértelmezett I/O ütemezője a Completely Fair Queuing (CFQ) ütemező. Az eredeti CFQ I/O ütemezőt Jens Axboe írta még 2003-ban Andrea Arcangeli Stochastic Fair Queueing I/O scheduler ötlete alapján. A CFQ az eltelt évek alatt számos revízión esett át.
A CFQ legelőször 2004. májusában bukkant fel a 2.6-os mainline kernelben (2.6.6) opcionális I/O ütemezőként. Akkor még futási időben nem, csak boot időben lehetett beállítani az "elevator=cfq" kernelparaméteren keresztül. A 2.6.10-es kernelben már futási időben is kiválasztható volt a /sys/block/<block_device>/queue/scheduler változón keresztül.
A CFQ a mainline kernelben 2006. szeptemberében vált alapértelmezett I/O ütemezővé, az Anticipatory I/O scheduler-t váltva. Jelenleg, az aktuális 3.x-es mainline kernelekben három I/O ütemező közül választhatunk. Az alapértelmezett a CFQ, de mellette elérhető még a deadline és a noop is.

Pár nappal ezelőtt a Red Hat alkalmazásában álló Vivek Goyal azzal fordult az LKML tagságához, hogy megváltoztatná a kernel alapértelmezett I/O ütemezőjét CFQ-ról deadline-ra. Vitára bocsátotta ötletét.

Vivek arra volt kíváncsi, hogy ésszerű-e még alapértelmezettként a CFQ-t szállítani. A CFQ általában jól teljesít lassú, rotációs médiák (pl. SATA eszközök) esetén. Viszont gyakran alulteljesít gyorsabb tárolóeszközökkel (pl. RAID tömbök, SSD-k, virtualizált lemezek).

Vivek tudja, hogy nincs egy jó válasz minden tárolótípusra és terhelésre, de szerinte ésszerűbb lenne a SATA kivételével minden eszköz esetén alapértelmezettként a deadline I/O ütemezőt beállítani.

Jens Axboe szerint értelmesebb lenne minden egymagában álló (vagyis nem RAID-be szervezett) rotációs eszköznél a CFQ-t használni, illetve minden RAID és nem rotációs elven működő eszköznél deadline I/O ütemezőt használni alapértelmezettként.

A thread itt.

( trey | 2012. 04. 14., szo – 19:35 )

Mikor SSD-re váltottam, az elsők közt állítottam át a cfq-t deadline-ra. Mérni nem nagyon mértem, de már csak használat közben is érezni véltem, hogy a deadline előnyösebb.

--
trey @ gépház

Hülyeséget írtam, de nem azért, mert ne lenne értelme a request merge-nek, hanem mert a noop is elvégzi azt.

Szóval a noopnak tényleg lehet létjogosultsága SSD-n és FC-n, de nem tudnék valódi előnyt mondani a deadline-al szemben. Ellenben semmit nem garantál, ami egy kézzel fogható hátránya interaktív környezetben.

( Dwokfur v | 2012. 04. 14., szo – 19:58 )

A SATA RAID az meg elsősorban RAID-nek számít ilyen szempontból?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Szerintem általános szabályt nehéz lenne felállítani, mivel vannak erősebb (hardveres) SATA RAID-ek, meg vannak szoftveres (aka. fake|host) RAID megoldások, ahol a RAID funkciókat a host gép CPU-ja végzi. Legjobb szerintem tesztelni. Szerencsére az IO ütemezőt futási időben át lehet váltani, így a tesztelés nagyon egyszerű.

--
trey @ gépház

( uid_228 | 2012. 04. 14., szo – 20:15 )

A "független, szabad, közösségi fejlesztésű Linux operációs rendszer" megint arra megy, amerre a Redhat üzleti érdeke megkívánja? :) Pontosan azokon a médiumokon teljesítene jobban a deadline, amiket a Redhat ügyfelei jellemzően használnak vállalati szegmensben. Még a virtualizációt is megemlíti.

Vagy én olvasok rosszul a sorok között? :))

--
Java apps are nothing more than sophisticated XML-to-exception converters.

( prion | 2012. 04. 14., szo – 21:11 )

nekem volt egy időszak amikor nagy fileokat másoltam sokat vinyák és partíciók között és CFQ alatt érezhetően csökkent bizonyos dolgokban a rendszer reszponzivitása. deadline teljesen jó volt ilyen szempontból.

Egyszer nagyon régen meguntam, hogy másoláskor az egész gép interaktív felhasználásra használhatatlan lett (különösen X alatt). Valahol rátaláltam erre a deadline scheduler beállításra. Egycsapásra elmúlt minden nyűgöm. Azóta az _összes_ általam menedzselt Linuxon ez van a kernel defaultnak megjelölve, és tisztább, szárazabb érzés... Nem érdekel, hogy SATA-ra talán jobb lenne egyesek szerint a CFQ. Szerintem nem volt sose jobb.

Szerintem ennek akkor volna értelme, ha volna olyan eset, ahol érdekel, hogy nem a deadline a legjobb. De nincs ilyen eset.

A CFQ egy esetben tud - elméletben - jobb lenni: ha szerveren használod, nincs interaktív tevékenység, gyenge/kevés diszked van, és masszívan túl van terhelve i/o-ban a géped. Ekkor "picit" jobb lesz, bár igazából szerintem teljesen mindegy, hiszen amúgy is gyenge i/o-ban a géped, az a kicsi elérhető többlet nem oszt, nem szoroz. Na pont ez az az eset, ahol igazából nem érdekel, hogy nem az optimálist kapom, ha meg véletlenül érdekelne, akkor meg beállítom a CFQ-t.

Nincs olyan, hogy minden esetre alkalmas. Nagyon jo pelda erre a Java meg a .NET JIT-tere, ahol sok esetben tobbet artunk, ha elore optimalizalunk.

Az, meg, hogy atlag desktopon az user allitgasson (sot, process utemezo eseten forditgasson) kernelt, az nonsense 2012-ben. (Iden mar nincs linux desktop meg smartphone eve?)

Manapsag ott kellene tartani, hogy a szamitogepnek illene alkalmazkodnia dinamikusan a felhasznalo szokasaihoz, nem a felhasznalonak kellene alapveto rendszerkomponensek konfigolasaval szoszolnie.

----------------
Lvl86 Troll - Think Wishfully™

( numen v | 2012. 04. 14., szo – 23:13 )

Jól értem, hogy ez a hír gyakorlatilag csak azokat érinti, akik maguknak pörgetik a kernelt, és – mivel eddig nem piszkálták – lényeges számukra, ha megváltozik az alapértelmezett ütemező?

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

( uid_2716 | 2012. 04. 15., v – 12:59 )

Lazán kapcsolódik: amíg a diszket kcryptd-n keresztül érjük el (titkosított partíció vagy LVM PV), addig tök mindegy. A kcryptd összemossa az összes IO kérést egyetlen folyamba, és az alatta lévő blokkütemező egyetlen forrásból (= kcryptd-ből) érkezőként lát mindent. Vagyis lényegtelen, milyen ütemezőt választunk, olyan, mint ha nem is lenne.

Sajnos ez egy borzasztóan idegesítő hiba. Példa: tegyük fel, hogy 10 percenként egyszer fut egy recollindex, vagy akármilyen program, amely szétszórva ír egy csomó kicsi blokkot, majd a végén kitol egy nagy fsync()-et. Ha ez ugyanazon a fizikai diszken (nem filesystem-en!) történik, mint ahol interaktív munkát végzünk, és mindkét jellegű hozzáférés átmegy a kcryptd-n valamilyen rétegben, akkor az interaktív munkánkban 6-13 másodperces fagyásokat is tapasztalhatunk. Lényegében amíg az fsync() fut az X processz kedvéért, addig az összes többi processz is fennakad, amelyik lapozásra kényszerül. Ez nyilván abszurd.

Ha jól tudom, dolgoznak a fiúk, hogy a kcryptd továbbpasszolja az eredeti kontextust az ütemezőnek (vagy valami más trükkön), de még csak kísérleti fázisban van.

( budee | 2012. 04. 17., k – 10:38 )

Az ugye mindenkinek megvan, hogy az ionice csak CFQ-val mukodik?