Luigi Rizzo предлагает (http://lists.freebsd.org/pipermail/freebsd-stable/2009-Janua...) пользователям FreeBSD 7-STABLE протестировать новую инфраструктуру для реализации внешних планировщиков ввода-вывода дисковой подсистемы, построенную на базе системы GEOM.
В качестве демонстрации возможностей системы, представлен планировщик, реализующий алгоритм "anticipatory scheduling". С целью уменьшения перемещений головок по диску планировщик пытается упорядочить поступающие запросы для более последовательного обращения к диску, вводя небольшую дополнительную задержку (2..5мс) перед фактической отправкой запроса и объединяя поступившие за это время новые запросы с ожидающими в очереди.
По приведенным результатам тестов видно, что включение данного механизма позволяет ускорить параллельное выполнение задач, требующих последовательного и произвольного доступа к дисковой подсистеме.URL: http://lists.freebsd.org/pipermail/freebsd-stable/2009-Janua...
Новость: http://www.opennet.me/opennews/art.shtml?num=19885
Вообще-то да, если конкретнее, то представлен фреймворк, а на его базе пока только один "упреждающий" алгоритм, но, глядишь такими темпами скоро поднапишут кучу планировщиков как самизнаетегде :)
Это что-то наподобие программного NCQ получается?
чтото вроде
> Это что-то наподобие программного NCQ получается?Похоже на то. И кстати, к линуксовому планировщику anticipatory, который занимается тем же самым, приписан комментарий большими буквами, что получить от него выгоду - почти как выиграть в лотерею. Ну и если винт умеет TCQ/NCQ, то толку вообще не будет.
А у меня, например, винт умеет NCQ, а материнка не поддерживает. Так что больше реализаций программных и нужных :)
> если винт умеет TCQ/NCQ, то толку вообще не будет.глубина очереди SATA NCQ - до 32 запросов. толк будет.
> Это что-то наподобие программного NCQ получается?во FreeBSD ata(4) не поддерживает NCQ на SATA-дисках
Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи?
->Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи?
также как и обычно. Кеш винта сбросится.
Вообще да, верхние уровни в любом случае не получат подтверждения, пока все данные не окажутся на диске. Но тормозить будет изрядно.
В драйвере ata сортировка запросов с начала времен присутствует, зачем ещё придерживать запросы на 2-5ms - непонятно. Лежали бы себе в очереди и выполнились бы когда подошло их время. А так ещё и пропустить их смещение можно, и что - головку обратно дергать ?Прикрутить этот планировщик к gmirror - тоже никакой возможности.
Сдается мне, джентельмены, что этот джентельмен не понял о чем идет речь. Позвольте объяснить. Задержака, как я понимаю, нужна для того, чтобы подождать - вдруг еще какие-нибудь запросы появятся, а мы их отсортируем и, возможно, получим выигрыш. Это как автобус, подъехавший к остановке, (по)высадивший пассажиров и ждущий, "а вдруг еще кто-то сейчас прибежит, и ему не придется ждать следующего автобуса". Дальше. Система как раз и занимается тем, что сортирует очередь, и исключает дерганье головки.
Сильно упрощенный пример: пришли запросы на чтение цилиндров 1, 10, 8, 3. Мы подождали и пришел запрос на чтение цилиндра 2. Отсортировали (1,2,3,8,10) и пошли читать в этом порядке. Если бы не сортировали - дергали бы головку. Если бы не ждали, то после чтения пришлось бы откатываться на 2й цилиндр, а так - выигрыш (хоть и незначительный, в данном случае).
В таком вот аскепте.
Премного благодарю за обьяснение, сударь (или мсье?)
Позвольте обратить Ваше внимание на следующий момент:
В любой момент времени для даной очереди запросов к даному устройству есть только один активный запрос (который сейчас отрабатывает механика устройства).
Все остальные запросы ждут своей очереди в очереди устройства (хардварной очереди самого устройства если это например scsi-винт или рейд или софтовой очереди драйвера устройства, например ata() для каждого канала держит свою очередь)Задержка отправки запроса на устройство приводит к тому, что его в очереди самого устройства не будет вообще эти 2-5ms.
А теперь рассмотрим последовательное выполнение запросов из очереди в порядке возрастания offset каждого bio
пусть в очереди лежат запросы ... , A < B, ...пришел запрос Y , такой что A < Y < B - мы отложили этот запрос Y в надежде что появится другой перед ним, не шлем его драйверу устройства
но допустим что нагрузка есть, очередь устройства не пуста, драйвер шлет запросы из нее по одному, и вот он выполнил последний запрос A у которого offset меньше чем у запроса Y
что теперь ?
теперь драйвер пошлет устройству запрос B у которого offset больше A
даже если теперь положить Y в очередь - ему придется ждать полного цикла пока очередь опять дойдет к нему.Даже если после выполнения A появится запрос X, который имеет offset A < X < Y < B - его уже бесполезно слать вместе с Y устройству в его очередь, поскольку устройство уже занято B
Согласен, что если X появится до выполнения A, то его можно успеть положить с Y вместе в очередь и оптимальный порядок нарушен не будет, но это произошло бы и в том случае если бы мы вообще не вводили никаких задержек.
А откуда система знает сколько у винта головок?
Более того, в серверах (и уже все чаще не только в них) используются RAID контроллеры, где подобная технология не только не поможет, но и реально может ухудшить перфоманс...
все современные винты в любой момент времени используют только одну головку
винты с независимыми головками и коромыслами настолько дорогие что проще и дешевле взять несколько обычных винтов
кроме того LBA адресация устроена так что для offset-A < offset-B будет trackN-A <= trackN-B
то есть в общем случае для любого одиночного винчестера пачку из нескольких запросов оптимальней всего выполнять в порядке увеличения LBA, для минимизации пути дергания головок
Как оно будет на SCSI и SAS ?
>Как оно будет на SCSI и SAS ?Это ведь надстройка через GEOM - там фиолетово что внизу...
>>Как оно будет на SCSI и SAS ?
>
>Это ведь надстройка через GEOM - там фиолетово что внизу...а ежели внизу FC диски с глубиной очереди 64?
Размышляя над вопросами ввода-вывода, я пришёл к таким выводам:Допустим, в очереди на исполнение находятся несколько процессов в состоянии ready. Выполняющийся в данный момент процесс сделал запрос на чтение. Нужно ли сразу отправлять этот запрос на диск (если диск не занят выполнением запросов)? Нет, не нужно, т.к. прочитанные данные должны вытеснить из кэша другие данные, которые могут понадобиться другим задачам. Нужно притормозить выполнение задачи, запросившей чтение с диска. Иными словами, нужно поддерживать баланс между количеством задач в очереди на исполнение и количеством отложенных запросов на чтение с диска. Разумеется, задания на чтение с диска можно и нужно переупорядочивать для того, чтобы диск мог выполнять их эффективнее.
Выводу неверные. Каким-то там процессам в будущем могут понадобиться (а могут и нет) данные из кеша, которые вы не хотите вытеснять, а здесь и сейчас уже точно нужные данные на чтение, что очевидно приоритетнее чего-то там неопределенного в далеком будущем. Задержка нужна для того чтобы оптимизировать движение головок, не более. В SSD дисках стоит самый простой планировщик из возможных безо всяких задержек. Так что думайте еще.
Я конечно хотел сказать 'для ssd дисков'