| 1.1, terminus (ok), 14:25, 21/01/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вообще-то да, если конкретнее, то представлен фреймворк, а на его базе пока только один "упреждающий" алгоритм, но, глядишь такими темпами скоро поднапишут кучу планировщиков как самизнаетегде :)
| | |
| |
| 2.4, const86 (ok), 15:03, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Это что-то наподобие программного NCQ получается?
Похоже на то. И кстати, к линуксовому планировщику anticipatory, который занимается тем же самым, приписан комментарий большими буквами, что получить от него выгоду - почти как выиграть в лотерею. Ну и если винт умеет TCQ/NCQ, то толку вообще не будет.
| | |
| |
| 3.11, Аноним (11), 19:44, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
А у меня, например, винт умеет NCQ, а материнка не поддерживает. Так что больше реализаций программных и нужных :)
| | |
| 3.12, csdoc (ok), 19:50, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> если винт умеет TCQ/NCQ, то толку вообще не будет.
глубина очереди SATA NCQ - до 32 запросов. толк будет.
| | |
|
| 2.14, Аноним (-), 20:08, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Это что-то наподобие программного NCQ получается?
во FreeBSD ata(4) не поддерживает NCQ на SATA-дисках
| | |
|
| 1.5, Guest (??), 17:01, 21/01/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи?
| | |
| 1.6, Rudik (?), 17:14, 21/01/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 ->Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи?
также как и обычно. Кеш винта сбросится.
| | |
| |
| 2.7, Guest (??), 17:20, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вообще да, верхние уровни в любом случае не получат подтверждения, пока все данные не окажутся на диске. Но тормозить будет изрядно.
| | |
|
| 1.8, zuborg (?), 18:38, 21/01/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 В драйвере ata сортировка запросов с начала времен присутствует, зачем ещё придерживать запросы на 2-5ms - непонятно. Лежали бы себе в очереди и выполнились бы когда подошло их время. А так ещё и пропустить их смещение можно, и что - головку обратно дергать ?
Прикрутить этот планировщик к gmirror - тоже никакой возможности.
| | |
| |
| 2.10, dev (??), 19:22, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
Сдается мне, джентельмены, что этот джентельмен не понял о чем идет речь. Позвольте объяснить. Задержака, как я понимаю, нужна для того, чтобы подождать - вдруг еще какие-нибудь запросы появятся, а мы их отсортируем и, возможно, получим выигрыш. Это как автобус, подъехавший к остановке, (по)высадивший пассажиров и ждущий, "а вдруг еще кто-то сейчас прибежит, и ему не придется ждать следующего автобуса". Дальше. Система как раз и занимается тем, что сортирует очередь, и исключает дерганье головки.
Сильно упрощенный пример: пришли запросы на чтение цилиндров 1, 10, 8, 3. Мы подождали и пришел запрос на чтение цилиндра 2. Отсортировали (1,2,3,8,10) и пошли читать в этом порядке. Если бы не сортировали - дергали бы головку. Если бы не ждали, то после чтения пришлось бы откатываться на 2й цилиндр, а так - выигрыш (хоть и незначительный, в данном случае).
В таком вот аскепте.
| | |
| |
| 3.15, zuborg (?), 20:38, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
Премного благодарю за обьяснение, сударь (или мсье?)
Позвольте обратить Ваше внимание на следующий момент:
В любой момент времени для даной очереди запросов к даному устройству есть только один активный запрос (который сейчас отрабатывает механика устройства).
Все остальные запросы ждут своей очереди в очереди устройства (хардварной очереди самого устройства если это например 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 вместе в очередь и оптимальный порядок нарушен не будет, но это произошло бы и в том случае если бы мы вообще не вводили никаких задержек.
| | |
| |
| |
| 5.19, ReWire (??), 09:21, 22/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Более того, в серверах (и уже все чаще не только в них) используются RAID контроллеры, где подобная технология не только не поможет, но и реально может ухудшить перфоманс...
| | |
| 5.22, zuborg (?), 14:47, 22/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
все современные винты в любой момент времени используют только одну головку
винты с независимыми головками и коромыслами настолько дорогие что проще и дешевле взять несколько обычных винтов
кроме того LBA адресация устроена так что для offset-A < offset-B будет trackN-A <= trackN-B
то есть в общем случае для любого одиночного винчестера пачку из нескольких запросов оптимальней всего выполнять в порядке увеличения LBA, для минимизации пути дергания головок
| | |
|
|
|
|
| |
| 2.13, terminus (ok), 19:57, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Как оно будет на SCSI и SAS ?
Это ведь надстройка через GEOM - там фиолетово что внизу...
| | |
| |
| 3.16, sds (?), 21:24, 21/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Как оно будет на SCSI и SAS ?
>
>Это ведь надстройка через GEOM - там фиолетово что внизу...
а ежели внизу FC диски с глубиной очереди 64?
| | |
|
|
| 1.17, Дмитрий Ю. Карпов (?), 21:28, 21/01/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Размышляя над вопросами ввода-вывода, я пришёл к таким выводам:
Допустим, в очереди на исполнение находятся несколько процессов в состоянии ready. Выполняющийся в данный момент процесс сделал запрос на чтение. Нужно ли сразу отправлять этот запрос на диск (если диск не занят выполнением запросов)? Нет, не нужно, т.к. прочитанные данные должны вытеснить из кэша другие данные, которые могут понадобиться другим задачам. Нужно притормозить выполнение задачи, запросившей чтение с диска. Иными словами, нужно поддерживать баланс между количеством задач в очереди на исполнение и количеством отложенных запросов на чтение с диска. Разумеется, задания на чтение с диска можно и нужно переупорядочивать для того, чтобы диск мог выполнять их эффективнее.
| | |
| |
| 2.20, Аноним (11), 10:00, 22/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
Выводу неверные. Каким-то там процессам в будущем могут понадобиться (а могут и нет) данные из кеша, которые вы не хотите вытеснять, а здесь и сейчас уже точно нужные данные на чтение, что очевидно приоритетнее чего-то там неопределенного в далеком будущем. Задержка нужна для того чтобы оптимизировать движение головок, не более. В SSD дисках стоит самый простой планировщик из возможных безо всяких задержек. Так что думайте еще.
| | |
|
|
