FIOPS - új, IOPS-alapú IO ütemező Linuxhoz

Kernel

Az Intel alkalmazásában álló Shaohua Li nemrég küldte be véleményezésre FIOPS névre hallgató IO ütemezőjét a Linux Kernel Mailing List-re (LKML). Az új ütemező kifejezetten flash-alapú adattároló-eszközökhöz készült. A flash-alapú adattárolók más karakterisztikájúak mint a hagyományos, pörgő lemezek. Ebből kifolyólag más ütemezési algoritmust is kívánnak. Az ütemező egyelőre kezdetleges állapotban van, a szerző első körben arra kíváncsi, hogy az alapötlet mennyire nyeri el a közösség tetszését. A thread itt kezdődik.

( cherockee v | 2012. 01. 09., h – 22:16 )

Csak laikusként: Mennyi teljesítménybeli különbséget hoz egy ilyen paradigmaváltás? Nem az SSD-HDD összehasonlításban, csak tisztán az IO ütemező cseréjéből eredő érdekel, akár tippelésként.

Próbálj ki pár ütemezőt a saját gépeden, desktop felhasználás közben, és meg fogod látni a különbséget. Például, kiszolgálókon általában van néhány kitüntetett folyamat (httpd, db, ez-az) amiktől nem szerencsés gyakran elvenni a futási jogot, optimális esetben jórészt ők futnak (így tudja a feladatát jól ellátni), míg desktopon az akár több tucat, dinamikusan használt, ide-oda váltogatott folyamatok esetén ez kevésbé jó, mert ilyenkor hatásosabban működik a rendszer, ha az ütemező minél inkább fair módon válogat. Az I/O ütemezés ugyan teljesen más, de pár alapgondolatot így megragadhatsz. Ahogy a cikk írja, teljesen más a diszk technológia, így az arra illő ütemezést kell használni.

--
http://neurogadget.com/

Inkább úgy mondanám, hogy a szerveren sokszor az áteresztőképességre megy az optimalizálás, a válaszidő rovására. Desktopon viszont kompromisszumot kell találni, az sokkal válaszidő-érzékenyebb. Zene- vagy videolejátszás pár ms-os kimaradása is zavaró, szerveren pár 100 ms legtöbbször észre sem vehető a szolgáltatás minőségében, hacsak nem valami kifejezetten realtime dologról van szó.

HDD-nél kemény kompromisszum van, a fair ütemezés és gyors válaszidő ára több seekelés volt (nem lehet hosszú ideig kitartani egy folyamat kiszolgálásánál), ami a aránytalanul nagyot ártott az átlagos áteresztőképességnek. SSD-knél sokkal kevésbé költséges a seekelés, valamint nincs különbség a seek időkben attól függően, hogy a címtartományban honnan hova ugrunk, tehát nem kell "elevator" optimalizálást csinálni.

Viszont pl az írásműveletek összevonására nagy szükség van, a kis blokkméretű random írás a flash halála (ugyanis sokkal nagyobb blokkokat kell törölni egy kis blokknyi adat felülírásakor - ez a write amplification), nemcsak teljesítmény, hanem élettartam miatt is.
---
Internet Memetikai Tanszék

Ha kimérik, megjavítjuk ;) mi az alapos tervezésen felül nem végzünk preoptimalizációt sem a kódban se a szerveren, hanem a mérésekkel alátámasztott szűk keresztmetszeten alakítunk, hogy jó legyen. Az átlag felhasználó (aki nem használ firebugot) észre sem vesz semit az egészből, aki meg mér, meg fizet, annak optimalizálunk.
_____________________
Liferay Service Builder, a sötét oldal

Extrém esetben elég nagyot – egyszer pörgettem magamnak egy kernelt, és ott az ütemezőnél azt hiszem, csak egy folyamat fért hozzá a lemezhez, és zárolta, míg nem végzett. FIXME, rég volt, és már nem találok semmilyen referenciát.

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

Az interneten, itt-ott állítják, hogy az alapértelmezett cfq-t érdemes deadline-ra (vagy noop-ra) tenni SSD-nél. Én egy ideje próbálgatom, nekem most deadline kb. fél éve. Amikor ezzel játszottam _érzésre_ ez adta valóban a legjobban, így maradt ez. Szerencsére menet közben állítható, így aki akar vele játszani, az egyszerűen tud.

--
trey @ gépház