В наблюдениях буферизованный ввод-вывод получает большую пропускную способность с Linux BFQ по сравнению с прямым вводом-выводом. Будет ли так работать Linux I?O с BFQ

Следующий эксперимент в Linux использует
- диск NVMe
- BFQ как планировщик ввода / вывода для NVMe с low_latency=0 и
- задача, которая заполняет диск запросами ввода-вывода, кратными размеру блока диска.

В настройке 1
у нас есть экземпляр задачи, работающий с приоритетом io в реальном времени (ionice -c1) и записывающий DIRECT на диск.
у нас есть еще один экземпляр вышеупомянутой задачи, работающий с обычным приоритетом (с максимальным усилием) и записывающий DIRECT на диск.
Как и ожидалось, мы видим, что задача, выполняемая с приоритетом в реальном времени, получает около 97% пропускной способности ввода-вывода (столько, сколько она потребляет)

В setup2,
мы запускаем вышеупомянутые задачи без DIRECT (используя кеш страниц).
у нас есть экземпляр задачи, работающей с приоритетом io в реальном времени (ionice -c1) и выполняющей запись в кеш страниц на диск.
у нас есть еще один экземпляр вышеупомянутой задачи, работающий с обычным приоритетом (с максимальным усилием) и записывающий через кеш страниц на диск.
Теперь мы видим, что пропускная способность диска распределяется поровну между двумя задачами.

В setup3,
у нас есть экземпляр задачи, работающий с приоритетом io в реальном времени (ionice -c1) и записывающий DIRECT на диск.
у нас есть еще один экземпляр вышеупомянутой задачи, работающий с обычным (максимальным усилием) приоритетом и записывающий через страницу шанс на диск
Теперь мы видим, что пропускная способность диска больше выделяется для задачи с низким приоритетом, использующей кеш страниц.

Стоит ли ожидать, что приоритетная задача реального времени в режиме реального времени получит более высокую пропускную способность и в настройках 2 и 3 под планировщиком ввода-вывода BFQ?

Благодарю.

0 ответов

Другие вопросы по тегам