Разные планировщики I/O для разных устройств

Или в /sys/block/sd*/queue/scheduler не всегда правда?

Всегда.

а как ты определил, что kyber стоит ставить? судя по форониксу, все эти планировщикаи сливаются друг другу и отключенному планироващику вообще(none), в зависимости от ситуации, типа диска и нагрузки

я себе ставлю bfq на hdd и none на nvme

а как ты определил, что kyber стоит ставить?

А никак пока что. Говорю же, на всякий случай, чтобы было.

судя по форониксу, все эти планировщикаи сливаются друг другу и отключенному планироващику вообще(none), в зависимости от ситуации, типа диска и нагрузки

Судя по ощущениям, то же самое:).

Однако, когда я заменил mq-deadline на none для ssd (для которого планировщик не нужен, говорили они), при начале свопинга клинило.

а как ты определил

А вот, кстати. Как лучше протестировать?

Тут где-то попался скрипт такой

[quote]#!/bin/sh
sudo clear
DISC="sdвставьтебукву"; \
cat /sys/block/$DISC/queue/scheduler; \
for T in mq-deadline kyber bfq; do \
     echo $T | tee /sys/block/$DISC/queue/scheduler; \
     cat /sys/block/$DISC/queue/scheduler; \
     sync; \
     echo 3 | tee /proc/sys/vm/drop_caches; \
     /sbin/hdparm -tT /dev/$DISC;\
     echo "----"; \
     sleep 10; \
done[/quote]

Вот, его погонял. Так результаты плавают сильнее от случая, чем от выбора планировщика.

Планировщики начинают работать когда у тебя нагрузка сильно сложнее чем последовательное чтение.

Человек без глубоких знаний даже и не поймет, что там можно планировать, при последовательном чтении.

Потому и нужен какой-то тест похитрее.

Создай две-три файловых системы на одном диске и пусти на них что-нибудь типа bonnie++

Может тебе стоит заменить

ACTION=="add|change", KERNEL=="sd[c-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="kyber"

на

ACTION=="add|change", KERNEL=="sd[c-z]",  ATTR{queue/scheduler}="kyber"

Я бы для начала попробовал так

SUBSYSTEM=="block", KERNEL=="sd[a-z]", ACTION=="add|change", ATTR{queue/rotational}=="0", TEST=="queue/scheduler", ATTR{queue/scheduler}="kyber"
SUBSYSTEM=="block", KERNEL=="sd[a-z]", ACTION=="add|change", ATTR{queue/rotational}=="1", TEST=="queue/scheduler", ATTR{queue/scheduler}="bfq"

udevadm trigger

PS А, и перед применением проверить, чтобы эти правила устанавливались только в одном месте, а не в пятнадцати разных файлах.

Спасибо, так сработало.

Не полностью понял, зачем это крутящееся-некрутящееся? Это сообщение планировщику, под какое устройство оптимизировать свою работу?

Это для всех невращающихся устройств включать kyber, а для всех вращающихся устройств включать bfq? Спасибо, может оказаться полезным.

проверить, чтобы эти правила устанавливались только в одном месте, а не в пятнадцати разных файлах.

А как проверить?

тред не читал:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",ATTR{queue/scheduler}="cfq"

Во всяком случае на ноутбуке с Ubuntu 16.04 было так.

С тех пор noop и cfq исчезли, только blk-mq остались.

А флешки и SD карточки тоже с noop работали?

Создай две-три файловых системы на одном диске и пусти на них что-нибудь типа bonnie++

И вот еще увидел.

https://github.com/axboe/fio

Но для этого всего я на данный момент умственно не готов.

С тех пор noop и cfq исчезли, только blk-mq остались.

при желании можно доустановить

А флешки и SD карточки тоже с noop работали?

«noop» самый простой - FIFO, у флешек и SD карт как и у SSD свой контроллер, он сам разрулит как лучше организовать очередь внутри своей структуры.

uname -v -r
5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020

А, вроде как, ядром 5.3 и новее non-multiqueue планировщики не поддерживаются. Но это тоже ладно.

Какие преимущества у non-multiqueue перед multiqueue? Можно, конечно, рассудить, что раз нет NVMe, а есть ssd и hdd на sata3 и флешки-карточки на usb, то от multiqueue и пользы нет. А какой от multiqueue вред? Нагрузка на процессор? Вот её не замечал как раз. Когда были клины при свопинге, процессору как раз вообще заняться нечем было.

ядром 5.3 и новее

да я щас особо и не отслеживаю, там туда такого понапихано

когда были клины при свопинге, процессору как раз вообще заняться нечем было.

я рассматривал всю эту возню с точки зрения мобильных устройств, в плане энергосбережения и длительности автономной работы от батареи, чем дольше проц находится в покое тем меньше сожрет с батареи

Странно, что никто до сих пор не сказал, что у nvme другие имена блочных устройств. Из вики рача:

# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

У меня вопрос: будет ли это работать в облаках и прочих виртуалках? Потому что там обычно не все аттрибуты блочных устройств пробрасывают.

Планировщики начинают работать когда у тебя нагрузка сильно сложнее чем последовательное чтение.

При интенсивном своппинге последовательного чтения и не бывает - кэши отбрасываются, считываются снова. При нехватке памяти вообще диск постоянно мигает, даже если ничего не происходит. Имеет смысл тестировать планировщики под стрессом с нехваткой памяти.

Доброго времени суток, собственно говоря вопрос не такой и простой, а точнее говоря проще и быть не может ;) Пробовал разные, тестов море делал, но мне нужно было максимум выжить на чтение! Из debian подобных для VM - deadline! Noop прироста не дает, хотя казалось бы почему его не использовать, формирование очереди простое аки АК-47, первый вошел - первый вышел, но нет, прироста нет, показатели сравнимы с deadline ;(. CFQ - как же я на нем обломался… Не рекомендую, потому как он для IDE и явно отстает от выше упомянутых! Теперь касаемо Centos 8.x все тоже самое +- за исключениями!

Тестировалось на СХД - Huawei OceanStor 5600, raid 6.1, 15К SAS, FC. Размеры блоков брались начиная от 512 KiB - 5120 KiB, глубины очередей варьировались соответственно!

Причем самое смешное - задержка к примеру на CFQ минимальна - даже идеальна - 18-20 msec, но блок выше 2 MiB не поднимается и обратно с deadline - GAVG 60-120 msec, но блок поднимается до 4 MiB и как следствие на 100 GiB время выполнение многопоточного DD (10 потоков) на deadline примерно 5-6 минут, а CFQ примерно 10 минут!

Диски презентовались по разному:

• Общий лун на все диски для теста;
• Разные луны чтение и запись;
• Physical RDM.

Тестировалось все это при помощи DD, CAT, CP, FIO!

Настройки были разные - начиная от размера блоков, заканчивая самим планировщиком!