A CAM I/O ütemezőt commitolák a FreeBSD -current-be

FreeBSD

Warner Losh egy "Heads up"-ot küldött nemrég a freebsd-current@ levelezési listára, amelyben arról számolt be, hogy commitolták a FreeBSD -current ágába a CAM I/O ütemezőt, amelynek a működését az I/O Scheduling in FreeBSD’s CAM Subsystem dokumentum írja le. A tesztelés mellé némi figyelmeztetés is jár, így annak, aki kipróbálná, mindenképpen érdemes elolvasnia a levlista idevágó szálát.

( Zahy v | 2016. 04. 18., h – 08:59 )

No végigmentem a levlista archívumban a szálon. Az milyen súlyos, hogy kb a fele arról szól, hogy milyen színű legyen a biciklitároló (kell-e a _NETFLIX a nevébe). Ezen kívül alig van használható infó: szerepel egy szűk lista a problémás(nak tűnő) SSD-kről, meg hogy hogyan kell kikapcsolni. Meg elhangzik az a nagyon ködös infó, hogy mennyi mindent tud, és lehet hangolni. Remélem a PDF elolvasása után azért többet fogok tudni ezekről is, mert személy szerint jobban érdekel.

A jelenlegi IO-ütemező semmilyen szűrést, korlátozást vagy egyéb beleszólást nem engedélyez - egyszerű FIFO. Pl. nincs lehetőség azt mondani, hogy most akkor lelassítjuk az írást, mert az olvasás fontosabb. (A Netflix cache-gépei bizonyos, terhelési szempontból üresjáratok során frissítik a háttértárakon tárolt filmeket - de ilyenkor nem streamelnek, mert a frissítés nagyon megnöveli a read latency-t. Ezt szeretnék olyanra átállítani, hogy kisebb streaming terhelés esetén mehessen a frissítés *is*.)

A jelenlegi ütemező egyetlen sorba pakolja az IO-kéréseket és mint írtam FIFO-ként dolgozza fel ezt. Az új implementációban 3 sor jelenik meg: olvasás, írás, törlés. Két ütemező valósult meg: a vezérlőnek (control scheduler) nevezett, ami a régi megvalósítást "szimulálja" (és amennyiben eltérést tapasztalnak az eredeti működéshez képest, ezt módosítják); illetve a Netflix-féle, amiben megjelentek szabályozó modulok. Az eredeti ütemező fájdalommentes lecseréléséhez alkalmas az előbbi (control scheduler). Az utóbbihoz (Netflix-féle) jelenleg kétféle korlátozó modul tartozik, a "fairness bias" - ezzel lehet az olvasást/írást előnyben részesíteni. Illetve a sorhossz (queue depth) alapú korlátozás, ekkor az ütemező nem ütemez több adott tipusú kérést, ha a sor hossza eléri a korlátot. A korlátozó modulok egymástól függetlenek, és külön-külön vagy együtt használhatók. A jelenlegi megvalósítás statikus tuningot nyújt, a dinamikus tuningolás egyelőre csak elképzelés.

Jav:
újabb korlátozók jelentek meg (sávszélesség, ill iops alapú), és ezeket diszkenként lehet beállítani. Visszajelzések jelentek meg, és a dinamikus módosítás, amiknek segítségével az egyik fajta IO terheléstől függően szabályosható a másik fajta korlátozása.

Utolsó javítás: újraolvasva a kérdéses részt, az előző javítás mintha mégsem lenne a beolvasztott kódban.