форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от opennews (ok) on 21-Янв-09, 14:25
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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от terminus (ok) on 21-Янв-09, 14:25
Вообще-то да, если конкретнее, то представлен фреймворк, а на его базе пока только один "упреждающий" алгоритм, но, глядишь такими темпами скоро поднапишут кучу планировщиков как самизнаетегде :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от local (??) on 21-Янв-09, 14:34
Это что-то наподобие программного NCQ получается?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от Georges (ok) on 21-Янв-09, 15:01
	чтото вроде
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от const86 (ok) on 21-Янв-09, 15:03
	> Это что-то наподобие программного NCQ получается? Похоже на то. И кстати, к линуксовому планировщику anticipatory, который занимается тем же самым, приписан комментарий большими буквами, что получить от него выгоду - почти как выиграть в лотерею. Ну и если винт умеет TCQ/NCQ, то толку вообще не будет.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	11. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от Аноним (??) on 21-Янв-09, 19:44
	А у меня, например, винт умеет NCQ, а материнка не поддерживает. Так что больше реализаций программных и нужных :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от csdoc (ok) on 21-Янв-09, 19:50
	> если винт умеет TCQ/NCQ, то толку вообще не будет. глубина очереди SATA NCQ - до 32 запросов. толк будет.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	14. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от Аноним (??) on 21-Янв-09, 20:08
	> Это что-то наподобие программного NCQ получается? во FreeBSD ata(4) не поддерживает NCQ на SATA-дисках
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от Guest (??) on 21-Янв-09, 17:01
Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от Rudik on 21-Янв-09, 17:14
->Насколько безопасно его использование с точки зрения вырубания электричества в посреди записи? также как и обычно. Кеш винта сбросится.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от Guest (??) on 21-Янв-09, 17:20
	Вообще да, верхние уровни в любом случае не получат подтверждения, пока все данные не окажутся на диске. Но тормозить будет изрядно.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от zuborg on 21-Янв-09, 18:38
В драйвере ata сортировка запросов с начала времен присутствует, зачем ещё придерживать запросы на 2-5ms - непонятно. Лежали бы себе в очереди и выполнились бы когда подошло их время. А так ещё и пропустить их смещение можно, и что - головку обратно дергать ? Прикрутить этот планировщик к gmirror - тоже никакой возможности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от dev (??) on 21-Янв-09, 19:22
	Сдается мне, джентельмены, что этот джентельмен не понял о чем идет речь. Позвольте объяснить. Задержака, как я понимаю, нужна для того, чтобы подождать - вдруг еще какие-нибудь запросы появятся, а мы их отсортируем и, возможно, получим выигрыш. Это как автобус, подъехавший к остановке, (по)высадивший пассажиров и ждущий, "а вдруг еще кто-то сейчас прибежит, и ему не придется ждать следующего автобуса". Дальше. Система как раз и занимается тем, что сортирует очередь, и исключает дерганье головки. Сильно упрощенный пример: пришли запросы на чтение цилиндров 1, 10, 8, 3. Мы подождали и пришел запрос на чтение цилиндра 2. Отсортировали (1,2,3,8,10) и пошли читать в этом порядке. Если бы не сортировали - дергали бы головку. Если бы не ждали, то после чтения пришлось бы откатываться на 2й цилиндр, а так - выигрыш (хоть и незначительный, в данном случае). В таком вот аскепте.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от zuborg on 21-Янв-09, 20:38
	Премного благодарю за обьяснение, сударь (или мсье?) Позвольте обратить Ваше внимание на следующий момент: В любой момент времени для даной очереди запросов к даному устройству есть только один активный запрос (который сейчас отрабатывает механика устройства). Все остальные запросы ждут своей очереди в очереди устройства (хардварной очереди самого устройства если это например 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 вместе в очередь и оптимальный порядок нарушен не будет, но это произошло бы и в том случае если бы мы вообще не вводили никаких задержек.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от moralez on 22-Янв-09, 06:41
	А откуда система знает сколько у винта головок?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от ReWire (??) on 22-Янв-09, 09:21
	Более того, в серверах (и уже все чаще не только в них) используются RAID контроллеры, где подобная технология не только не поможет, но и реально может ухудшить перфоманс...
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от zuborg on 22-Янв-09, 14:47
	все современные винты в любой момент времени используют только одну головку винты с независимыми головками и коромыслами настолько дорогие что проще и дешевле взять несколько обычных винтов кроме того LBA адресация устроена так что для offset-A < offset-B будет trackN-A <= trackN-B то есть в общем случае для любого одиночного винчестера пачку из нескольких запросов оптимальней всего выполнять в порядке увеличения LBA, для минимизации пути дергания головок
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

9. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
Сообщение от Аноним (??) on 21-Янв-09, 19:16
Как оно будет на SCSI и SAS ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от terminus (ok) on 21-Янв-09, 19:57
	>Как оно будет на SCSI и SAS ? Это ведь надстройка через GEOM - там фиолетово что внизу...
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Во FreeBSD появился 'упреждающий' дисковый планировщик"	+/–
	Сообщение от sds on 21-Янв-09, 21:24
	>>Как оно будет на SCSI и SAS ? > >Это ведь надстройка через GEOM - там фиолетово что внизу... а ежели внизу FC диски с глубиной очереди 64?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "Странный алгоритм"	+/–
Сообщение от Дмитрий Ю. Карпов on 21-Янв-09, 21:28
Размышляя над вопросами ввода-вывода, я пришёл к таким выводам: Допустим, в очереди на исполнение находятся несколько процессов в состоянии ready. Выполняющийся в данный момент процесс сделал запрос на чтение. Нужно ли сразу отправлять этот запрос на диск (если диск не занят выполнением запросов)? Нет, не нужно, т.к. прочитанные данные должны вытеснить из кэша другие данные, которые могут понадобиться другим задачам. Нужно притормозить выполнение задачи, запросившей чтение с диска. Иными словами, нужно поддерживать баланс между количеством задач в очереди на исполнение и количеством отложенных запросов на чтение с диска. Разумеется, задания на чтение с диска можно и нужно переупорядочивать для того, чтобы диск мог выполнять их эффективнее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Странный алгоритм"	+/–
	Сообщение от Аноним (??) on 22-Янв-09, 10:00
	Выводу неверные. Каким-то там процессам в будущем могут понадобиться (а могут и нет) данные из кеша, которые вы не хотите вытеснять, а здесь и сейчас уже точно нужные данные на чтение, что очевидно приоритетнее чего-то там неопределенного в далеком будущем. Задержка нужна для того чтобы оптимизировать движение головок, не более. В SSD дисках стоит самый простой планировщик из возможных безо всяких задержек. Так что думайте еще.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	21. "Странный алгоритм"	+/–
	Сообщение от Аноним (??) on 22-Янв-09, 10:01
	Я конечно хотел сказать 'для ssd дисков'
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема