https://www.opennet.dev/openforum/vsluhforumID3/48339.html Luigi Rizzo предлагает (http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html) пользователям FreeBSD 7-STABLE протестировать новую инфраструктуру для реализации внешних планировщиков ввода-вывода дисковой подсистемы, построенную на базе системы GEOM.<br><br><br>В качестве демонстрации возможностей системы, представлен планировщик, реализующий алгоритм "anticipatory scheduling". С целью уменьшения перемещений головок по диску планировщик пытается упорядочить поступающие запросы для более последовательного обращения к диску, вводя небольшую дополнительную задержку (2..5мс) перед фактической отправкой запроса и объединяя поступившие за это время новые запросы с ожидающими в очереди.<br><br><br>По приведенным результатам тестов видно, что включение данного механизма позволяет ускорить параллельное выполнение задач, требующих последовательного и произвольного доступа к дисковой подсистеме.<br><br>URL: http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html<br>Новость: http://www.opennet.ru/opennew https://www.opennet.dev/openforum/vsluhforumID3/48339.html#22 Thu, 22 Jan 2009 11:47:38 GMT все современные винты в любой момент времени используют только одну головку<br>винты с независимыми головками и коромыслами настолько дорогие что проще и дешевле взять несколько обычных винтов<br>кроме того LBA адресация устроена так что для offset-A &lt; offset-B будет trackN-A &lt;= trackN-B<br>то есть в общем случае для любого одиночного винчестера пачку из нескольких запросов оптимальней всего выполнять в порядке увеличения LBA, для минимизации пути дергания головок<br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#21 Thu, 22 Jan 2009 07:01:16 GMT Я конечно хотел сказать 'для ssd дисков'<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#20 Thu, 22 Jan 2009 07:00:29 GMT Выводу неверные. Каким-то там процессам в будущем могут понадобиться (а могут и нет) данные из кеша, которые вы не хотите вытеснять, а здесь и сейчас уже точно нужные данные на чтение, что очевидно приоритетнее чего-то там неопределенного в далеком будущем. Задержка нужна для того чтобы оптимизировать движение головок, не более. В SSD дисках стоит самый простой планировщик из возможных безо всяких задержек. Так что думайте еще.<br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#19 Thu, 22 Jan 2009 06:21:42 GMT Более того, в серверах (и уже все чаще не только в них) используются RAID контроллеры, где подобная технология не только не поможет, но и реально может ухудшить перфоманс...<br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#18 Thu, 22 Jan 2009 03:41:52 GMT А откуда система знает сколько у винта головок? <br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#17 Wed, 21 Jan 2009 18:28:26 GMT Размышляя над вопросами ввода-вывода, я пришёл к таким выводам:<br><br>Допустим, в очереди на исполнение находятся несколько процессов в состоянии ready. Выполняющийся в данный момент процесс сделал запрос на чтение. Нужно ли сразу отправлять этот запрос на диск (если диск не занят выполнением запросов)? Нет, не нужно, т.к. прочитанные данные должны вытеснить из кэша другие данные, которые могут понадобиться другим задачам. Нужно притормозить выполнение задачи, запросившей чтение с диска. Иными словами, нужно поддерживать баланс между количеством задач в очереди на исполнение и количеством отложенных запросов на чтение с диска. Разумеется, задания на чтение с диска можно и нужно переупорядочивать для того, чтобы диск мог выполнять их эффективнее.<br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#16 Wed, 21 Jan 2009 18:24:50 GMT &gt;&gt;Как оно будет на SCSI и SAS ? <br>&gt;<br>&gt;Это ведь надстройка через GEOM - там фиолетово что внизу... <br><br>а ежели внизу FC диски с глубиной очереди 64?<br> https://www.opennet.dev/openforum/vsluhforumID3/48339.html#15 Wed, 21 Jan 2009 17:38:10 GMT Премного благодарю за обьяснение, сударь (или мсье?)<br>Позвольте обратить Ваше внимание на следующий момент:<br>В любой момент времени для даной очереди запросов к даному устройству есть только один активный запрос (который сейчас отрабатывает механика устройства). <br>Все остальные запросы ждут своей очереди в очереди устройства (хардварной очереди самого устройства если это например scsi-винт или рейд или софтовой очереди драйвера устройства, например ata() для каждого канала держит свою очередь)<br><br>Задержка отправки запроса на устройство приводит к тому, что его в очереди самого устройства не будет вообще эти 2-5ms.<br><br>А теперь рассмотрим последовательное выполнение запросов из очереди в порядке возрастания offset каждого bio<br>пусть в очереди лежат запросы ... , A &lt; B, ...<br><br>пришел запрос Y , такой что A &lt; Y &lt; B - мы отложили этот запрос Y в надежде что появится другой перед ним, не шлем его драйверу устройства<br><br>но допустим что нагрузка есть, очередь устройства не пуста, драйвер шлет запросы из нее по одному https://www.opennet.dev/openforum/vsluhforumID3/48339.html#14 Wed, 21 Jan 2009 17:08:17 GMT &gt; Это что-то наподобие программного NCQ получается?<br><br>во FreeBSD ata(4) не поддерживает NCQ на SATA-дисках<br>