Этот вопрос связан с фио (гибкий тестер ввода-вывода) управляет очередями ввода-вывода для хранилища NVME (в частности, твердотельных накопителей) при использовании libaio двигатель.
Для тестирования я использую Ubuntu 14.04 и коммерческий SSD от nvme.
Я провожу эксперимент с fio следующими аргументами:
direct=1
numjobs=256
iodepth=1
ioengine=libaio
group_reporting
В этом примере предположим, что устройство nvme рекламирует / поддерживает 10 очереди ввода-вывода создания с максимальной глубиной очереди 64. Вы можете предположить, что 10 созданий очереди были успешными как часть инициализации.
На основании вышеуказанных параметров и ограничений, "How would fio use the queues, for I/O commands?" ИЛИ, чтобы сузить объем "Does the iodepth argument in fio directly equate to nvme_queue_depth for the test" вот в чем вопрос.
Я ожидаю, что под капотом будет что-то вроде ниже, но у меня нет правильной информации.
пример сценария 1:
создает ли fio 256 заданий / потоков, которые пытаются отправить ввод-вывод в nvme_queues и в любой момент сохранить хотя бы 1 команду ввода-вывода в 10 nvme_queues. Если задание видит, что очередь заполнена (т.е. если (один) cmd ввода / вывода присутствует в nvme_queue, просто пытается отправить в другие 9 nvme_queues или, возможно, циклические переборы, пока не найдет пустую очередь)пример сценария 2:
выполняет потоки / задания fio 256, на самом деле не соблюдают iodepth == nvme_quedepth, который будет использоваться для этого теста, и все равно отправляют несколько операций ввода-вывода. Так, например, каждый поток просто отправляет 1 команду ввода-вывода в nvme_queues без какой-либо проверки глубины команд в 10 nvme_queues. Другими словами, 256 потоков пытаются поддерживать примерно 25 или 26 операций ввода-вывода в ожидании / в полете в 10 nvme_queues.
Ссылка на определение iodepth из документации fio.
Верны ли оба сценария? и есть ли способ убедиться в этом с помощью эксперимента.
прохождение спецификации для nvme и fio на самом деле неясно, как обрабатывается этот сценарий, или является расплывчатым.
Обновить: Ниже представлены два сценария в формате изображения. https://imgur.com/OCZtwgM (невозможно вставить) верхний - сценарий 1, нижний - scn. 2
Обновление 2: Извините, если вопрос нечеткий, но я попытаюсь улучшить его, расширив его немного дальше.
Насколько я понимаю, между устройством и fio. Следовательно, вопрос касается многих уровней кода и / или протокола, которые здесь задействованы. перечислить их
1. Fio (приложение) и libaio
2. Ядро Linux / ОС
3. Драйвер Nvme
4. Контроллер SSD накопителя и код.
Два описанных выше сценария - это расплывчатая попытка объяснить на очень высоком уровне, чтобы ответить на мой собственный вопрос, поскольку я далеко не эксперт по вышеупомянутым слоям.
Согласно ответу ниже кажется scenario 1 слабо актуален. И хотел узнать немного больше об общей политике и предсказуемости на всех уровнях. Частичные объяснения в порядке, надеюсь, объединение в полное.
так что третья наивная перефразировка вопроса будет "how does fio issue traffic and how they really end up the storage nvme_queues?"
TL; DR; структура представления ввода-вывода пользовательского пространства, когда ввод-вывод покидает ядро, описана в Linux Block IO: представление доступа к SSD с несколькими очередями в многоядерных системах бумага.
"How would fio use the queues, for I/O commands?"ИЛИ, чтобы сузить объем"Does the iodepth argument in fio directly equate to nvme_queue_depth for the test"
Это мышление немного слишком шерстистый, и я бы предостерегал от этого. «Как fio будет использовать очереди для команд ввода-вывода?» - не только до фио. «Приравнивается ли аргумент iodepth в fio напрямую к nvme_queue_depth для теста» - возможно, но, вероятно, нет? В вашем примере fio отправляет ввод-вывод ядру, но ядро, в свою очередь, может решить преобразовать этот ввод-вывод перед тем, как отправить его на диск (см. ответ на вопрос «Что на самом деле означает iodepth в тестах fio? Это глубина очереди?»).
сценарий 1: создает ли fio 256 заданий / потоков, которые пытаются отправить ввод-вывод в nvme_queues и в любой момент сохранить хотя бы [sic] 1 команду ввода-вывода в 10 nvme_queues
Вроде (но s / jobs / процессы /). Каждое задание (которое, вероятно, будет отображаться в процессе, если ваш пример завершен) отправляет ядру не более одного ввода-вывода. Однако имейте в виду, что fio ничего не знает о том, что может делать ваш диск, и находится во власти того, что ваше ядро решает делать в отношении планирования операций ввода-вывода и каждого отдельного процесса fio.
пример сценария 2
Боюсь, я не понимаю, потому что вы не привели отдельный пример. Делает "iodepth"в этом случае обратитесь к fio's iodepth параметр?
Верны ли оба сценария?
Я не понимаю ваш сценарий 2 и сценарий 1 будут иметь много накладных расходов, и мы не знаем, что ядро будет делать с вводом-выводом, поэтому я не думаю, что на это можно дать окончательный ответ (например, я немного подозрительно, что ваши диски NVMe появляются с узлами устройств SCSI ...).
Я бы порекомендовал посмотреть, что iostat говорит, что пока выполняются задания fio, чтобы получить представление, но выполнение одного ввода-вывода для каждого задания является ОЧЕНЬ неэффективным способом отправки ввода-вывода и повлечет за собой много накладных расходов (что, вероятно, помешает вам достичь максимальной скорости). Как правило, вы устраиваете задание на представление как можно большего количества операций ввода-вывода и ТОЛЬКО затем вводите дополнительные задания.
Обновить
Судя по диаграмме, которую вы включили в свое обновление, мы более или менее находимся в том, что вы думаете как сценарий 2 (256 процессов, каждый из которых отправляет один ввод-вывод, диск NVMe имеет несколько очередей, каждая с отдельной глубиной, а не одна гигантская очередь), но представьте себе воронка из пользовательского пространства в ядро и другая (другая) воронка из ядра в очереди «диска» (давайте проигнорируем HW RAID и т. д.), а не какое-то однозначное сопоставление из процесса пользовательского пространства в дисковую очередь . Если вы не использовали драйвер пользовательского пространства для своего диска, у вас будет очень мало контроля над тем, в какую очередь будет попадать данный ввод-вывод, поскольку ядро абстрагирует это решение за вас. Например, ваши процессы могут переключаться между процессорами (по прихоти ядра), и у вас может даже быть несбалансированное количество процессов на одном физическом процессоре (по сравнению с количеством на других процессорах), что еще больше запутывает воду.
И хотел узнать немного больше об общей политике и предсказуемости на всех уровнях.
Вам, вероятно, придется проследить свой путь через слой блоков ядра, чтобы определить, зная, какую версию ядра вы используете. Кроме того, некоторые ядра Ubuntu 14.04 не поддерживали несколько очередей (см. Статья LWN для краткого обзора blk-mq) для дисков NVMe (думаю Поддержка blk-mq для устройств NVMe появилась в ядре 3.19) и это отсылает нас к моему комментарию «Я немного подозреваю, что ваши диски NVMe появляются с узлами устройств SCSI»). Есть газета под названием "Linux Block IO: представление доступа к SSD с несколькими очередями в многоядерных системах", в котором более подробно обсуждаются изменения и преимущества blk-mq и рассматриваются области 1–3. Скорее всего, вам лучше задать другой вопрос, если вам нужны подробности в области 4, но Кодирование для SSD дает стартовое резюме.
как fio выдает трафик и как они действительно попадают в хранилище nvme_queues?
Зависит от механизма ввода-вывода и выбранной вами конфигурации :-) Однако для примера конфигурации вы дали рисунки 2 и 5 «Представление доступа к твердотельным накопителям с несколькими очередями в многоядерных системах» бумажная обложка, что происходит под fio и «Что на самом деле означает iodepth в тестах fio? Это глубина очереди?» Ответ покрывает сам fio.