Wybieranie harmonogramu We/Wy Linuksa

Czytałem, że podobno można zmienić scheduler We / Wy dla konkretnego urządzenia na uruchomionym jądrze, zapisując do / sys/block/[dysk]/queue / scheduler. Na przykład mogę zobaczyć na moim systemie: 

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq]

Że domyślną wartością jest całkowicie sprawiedliwy harmonogram kolejkowania. Zastanawiam się, czy jest jakiś pożytek z WŁĄCZANIA wszystkich czterech schedulerów w moim niestandardowym jądrze. Wydaje się, że nie ma sensu mieć więcej niż jeden scheduler skompilowany, chyba że jądro jest inteligentne wystarczy, aby wybrać odpowiedni harmonogram dla właściwego sprzętu, w szczególności harmonogram "noop" dla dysków flash i jeden z innych dla tradycyjnego dysku twardego.

Czy tak jest?
Author: Robert S. Barnes, 2009-06-18
Source

4 answers

Jak udokumentowano w /usr/src/linux/Documentation/block/switching-sched.txt, harmonogram We/Wy na dowolnym urządzeniu blokowym może być zmieniany w czasie wykonywania. Mogą wystąpić pewne opóźnienia, ponieważ żądania poprzedniego harmonogramu są spłukiwane przed uruchomieniem nowego harmonogramu, ale można je zmienić bez problemów, nawet gdy urządzenie jest w ciężkim użyciu.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

Najlepiej byłoby, gdyby istniał jeden scheduler, który zaspokoi wszystkie potrzeby. Wydaje się, że jeszcze nie istnieje. Jądro często nie ma wystarczającej wiedzy, aby wybrać najlepszy harmonogram dla Twojego obciążenia:

  • Ramdisk) i innych nie rotacyjnych nośników (flash), gdzie próba przełożenia We/Wy jest stratą zasobów [17]}
  • Jest to prosty scheduler, który stara się ograniczyć opóźnienia.]}
  • cfq próbuje utrzymać uczciwość całego systemu przepustowości We / Wy

Domyślnym był anticipatory przez długi czas, i otrzymał wiele strojenia, ale był usunięte w 2.6.33 (początek 2010 roku). cfq stała się domyślna jakiś czas temu, ponieważ jej wydajność jest rozsądna, a uczciwość jest dobrym celem dla Systemów wieloużytkowych (a nawet komputerów stacjonarnych dla jednego użytkownika). Dla niektórych scenariuszy -- bazy danych są często używane jako przykłady, ponieważ mają już swoje własne osobliwe Schematy planowania i dostępu, i często są najbardziej {27]} ważną usługą (więc kogo obchodzi uczciwość?) -- anticipatory ma długą historię dostrajania się do najlepszych wyników na te obciążenia i deadline bardzo szybko przekazuje wszystkie żądania do urządzenia bazowego.

 107
Author: ephemient,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-06-30 17:29:14

Możliwe jest użycie reguły udev, aby pozwolić systemowi decydować o harmonogramie w oparciu o pewne cechy sprzętu.
Przykładowa reguła udev dla dysków SSD i innych dysków nie rotacyjnych może wyglądać następująco]} 

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Wewnątrz nowego pliku udev rules(np. /etc/udev/rules.d/60-ssd-scheduler.rules). Ta odpowiedź jest oparta na Debian wiki

Aby sprawdzić, czy dyski ssd użyją reguły, można wcześniej sprawdzić atrybut wyzwalacza: 

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done
 18
Author: Dani_l,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-02-03 10:20:50

Celem obsługi jądra jest to, że można je wypróbować bez ponownego uruchamiania; można następnie uruchamiać obciążenia testowe za pomocą sytemu, mierzyć wydajność, a następnie uczynić to standardowym dla aplikacji.

Na nowoczesnym sprzęcie klasy serwerowej tylko noop wydaje się być w ogóle przydatny. Inne wydają się wolniejsze w moich testach.

 7
Author: MarkR,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-17 21:24:42

Jądro Linuksa nie zmienia automatycznie harmonogramu IO w czasie wykonywania. Chodzi mi o to, że jądro Linuksa, na dzień dzisiejszy, nie jest w stanie automatycznie wybrać" optymalnego " harmonogramu w zależności od rodzaju dodatkowego urządzenia pamięci masowej. Podczas rozruchu lub podczas pracy można ręcznie zmienić harmonogram IO .

Domyślny harmonogram jest wybierany podczas uruchamiania na podstawie zawartości w pliku / linux-2.6 /block / Kconfig.iosched . Jednak to istnieje możliwość zmiany harmonogramu IO w czasie wykonywania przez echoING poprawną nazwę harmonogramu do pliku znajdującego się w /sys/block/[DEV]/queue/scheduler. Na przykład echo deadline > /sys/block/hda/queue/scheduler

 -6
Author: KZcoding,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-02-24 18:31:30