Připravované jádro verze 4.2 změní výchozí nastavení I/O plánovače CFQ, který poběží v IOPS režimu, pokud bude detekován SSD disk. To by mělo přinést vyšší výkon na SSD. Autorem malého patche je Tahsin Erdogan z Google, který zároveň v mailing listu vysvětlil princip: CFQ zpožďuje požadavky na disky, aby je lépe řadil kvůli menšímu seekování. To ale u SSD nemá smysl, protože není třeba čekat na žádné hlavičky, takže je lepší tento režim vypnout a sypat data na disk co nejdříve.
Linuxové jádro 4.2 změní nastavení plánovače pro lepší výkon SSD
8. 6. 2015
10
nových názorů
-
aaa (neregistrovaný)
Z mojho pochopenia schedulerom noop nerobi nic, co sa hodi pri dnes beznom NCQ, zvlast u SSD. Scheduler vacsinou len zerie CPU cas.
Scheduler ale moze zlucovat requesty, nez sa dostanu do disku a vdaka tomu sa pomoze vykonu - SSD nema rado viac prepisov jedneho 4kB bloku po sebe. Preto na SSD pouzivam deadline scheduler.
Druha moznost je, ze chcu spravit univerzalny scheduler fungujuci dobre aj pri SSD. Zaciatocnici si neradi nieco nastavuju a toto sa hodi.
-
trubicoid2 (neregistrovaný)
koukam na blbuntu (jiny mainstreamovy distro, kde bych sam nezmenil scheduler tu nemam) a je tam deadline defaultni (rotacni i ssd)
a k tomu slucovani slouzi jeste navic toto: cat /sys/block/sda/queue/nomerges
default 0 = slucovat; 1 = neslucovat, lepsi iops na ssd; mozna mensi zivotnost, jak rikas ty
nezavisi to na scheduleru, muze byt i noop + nomerge
-
Sten (neregistrovaný)
Slučování požadavků nedělá plánovač, ale fronta. Plánovač slouží pro případy, kdy jde na disk příliš mnoho požadavků. noop prostě nechá programy přistupovat tak, jak to stíhají, což třeba způsobuje, že odswapované programy mají smůlu, protože programy v paměti je ubijí, nebo databáze s nastavenými timeouty mohou být ubity nějakým velmi aktivním procesem a začít rollbackovat.
-
trubicoid2 (neregistrovaný)
tak ten jejich test mi dela s noop 23kiops, s deadline 26kiops a s cfq 20kiops, predpokladam, ze po oprave budou mit mozna 22kiops ...
sice v komentarich na phoronixu pisi, ze misto patchu staci
echo 0 > /sys/block/sdx/queue/iosched/slice_idle
toto mi vsak benchmark trochu zpomali
v komentarich na phoronixu taky pisi, ze cfq kvuli cloudum a cgroups, aby to umelo limitovat, takze tak
jeste vypada, ze konecne zacleni bfq :)
-
noop je dobrý na mobil, ale už na desktopu je nedostatečný. Plánovač má více funkcí než jen řadit požadavky podle hlaviček, sektorů atd. On také může řešit prioritu požadavků podle priority jejich procesů, zamezovat hladovým procesům zabírat celé pásmo, bránit zastarávání požadavků... Na mobilu (= jen několik HW zařízení a procesů, potřeba šetřit zdroje...) jsou zcela jiné požadavky než na serveru se stovkami aktivních procesů, uživatelů, zařízení, disků...
Zde je odkaz na slušný přehled různých plánovačů s výhodami a nevýhodami (jsou tam i ty androidí). Po prolistování je myslím jasné, že benchmarkování těchto technik je problém – holá přenosová rychlost není zdaleka všechno.
