Vlákno názorů k článku
Linuxové jádro 4.2 změní nastavení plánovače pro lepší výkon SSD od trubicoid2 - nema se na ssd pouzivat noop?

nema se na ssd pouzivat noop?

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.

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/qu­eue/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

nomerges ma jeste 2:

By default (0) all merges are enabled. When set to 1 only simple one-hit merges will be tried. When set to 2 no merge algorithms will be tried (including one-hit or more
complex tree/hash lookups).

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.

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/qu­eue/iosched/sli­ce_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 :)