Планировщик Noop - Noop scheduler

Расположение планировщиков ввода-вывода в упрощенной структуре ядра Linux.

В Планировщик NOOP самый простой Планировщик ввода / вывода для Ядро Linux. Этот планировщик был разработан Йенс Аксбо.

Обзор

Планировщик NOOP вставляет все входящие запросы ввода / вывода в простой ФИФО очереди и реализует слияние запросов. Этот планировщик полезен, когда определено, что хост должен нет попытаться изменить порядок запросов на основе содержащихся в них номеров секторов. Другими словами, планировщик предполагает, что хост не знает, как продуктивно изменять порядок запросов.

Есть (как правило) три основных ситуации, когда такая ситуация желательна:

  • Если планирование ввода-вывода будет обрабатываться на нижнем уровне стека ввода-вывода. Примеры нижних уровней, которые могут обрабатывать планирование, включают блочные устройства, интеллектуальные контроллеры RAID, сетевое хранилище или внешний контроллер, например подсистему хранения, доступ к которой осуществляется через коммутируемую сеть хранения данных.[1] Поскольку запросы ввода-вывода потенциально перепланированы на более низком уровне, изменение последовательности операций ввода-вывода на уровне хоста использует время центрального процессора для операций, которые будут просто отменены на более низком уровне, увеличивая задержку / уменьшая пропускную способность без каких-либо производственных причин.
  • Поскольку точные детали положения сектора скрыты от хост-системы. Примером может служить RAID-контроллер, который не выполняет планирование самостоятельно. Несмотря на то, что хост имеет возможность изменять порядок запросов, а контроллер RAID - нет, хост-системе не хватает возможности для точного изменения порядка запросов для уменьшения времени поиска. Поскольку хост не имеет возможности судить, лучше ли одна последовательность, чем другая, он не может оптимально реструктурировать активную очередь и, следовательно, должен передать ее устройству, которое (теоретически) более осведомлено о таких деталях.
  • Потому что движение головки чтения / записи недостаточно влияет на производительность приложения, чтобы оправдать накладные расходы на переупорядочение. Обычно это случается с невращающимися носителями, такими как флэш-накопители или твердотельные накопители (SSD).

Однако NOOP не обязательно является предпочтительным планировщиком ввода-вывода для описанных выше сценариев. Как и при любой настройке производительности, все рекомендации будут основаны на наблюдаемых моделях рабочей нагрузки (что подрывает способность создавать упрощенные практические правила). Если есть конкуренция за доступную пропускную способность ввода-вывода от других приложений, все еще возможно, что другие планировщики будут генерировать более высокую производительность благодаря более разумному разделению этой полосы пропускания для приложений, которые считаются наиболее важными. Например, запуск сервера каталогов LDAP может принести пользу срок Предпочтение чтения и гарантии задержки. В то же время пользователь с настольной системой, на которой запущено множество различных приложений, может захотеть получить доступ к CFQ или его способность устанавливать приоритет полосы пропускания для определенных приложений над другими (ionice ).

Если между приложениями нет разногласий, то выбор планировщика для трех перечисленных выше сценариев практически не дает никаких преимуществ. Это связано с невозможностью отменить приоритет операций одной рабочей нагрузки таким образом, чтобы сделать дополнительную емкость доступной для другой рабочей нагрузки. Другими словами, если пути ввода-вывода не насыщены и запросы для всех рабочих нагрузок не вызывают необоснованного смещения головок дисков (о чем знает операционная система), преимущество приоритизации одной рабочей нагрузки может создать ситуацию. где время ЦП, потраченное на планирование ввода-вывода, тратится впустую, вместо того, чтобы обеспечивать желаемые преимущества.

Ядро Linux также предоставляет номеры sysfs в качестве конфигурации, не зависящей от планировщика, что позволяет отключить логику слияния запросов блочного уровня либо полностью, либо только для более сложных попыток слияния.[2] Это снижает потребность в планировщике NOOP, поскольку накладные расходы большинства планировщиков ввода-вывода связаны с их попытками найти соседние секторы в очереди запросов, чтобы объединить их. Однако большинство рабочих нагрузок ввода-вывода выигрывают от определенного уровня слияния запросов даже в быстром хранилище с малой задержкой, таком как твердотельные накопители.[3][4]

Смотрите также

Рекомендации

  1. ^ «Выбор планировщика ввода-вывода для Red Hat Enterprise Linux 4 и ядра 2.6». Красная шляпа. Архивировано из оригинал на 2007-08-27. Получено 2007-08-10.
  2. ^ «Документация / блок / очередь-sysfs.txt». Документация ядра Linux. kernel.org. 1 декабря 2014 г.. Получено 14 декабря, 2014.
  3. ^ «6.4.3. Noop (документация по Red Hat Enterprise Linux 6)». Красная шляпа. 8 октября 2014 г.. Получено 14 декабря, 2014.
  4. ^ Пол Куэрна (15 августа 2014 г.). «Настроить флэш-накопители в экземплярах с высоким уровнем ввода-вывода как диски данных». Rackspace. Получено 15 декабря, 2014.

внешняя ссылка