|
ru.unix.bsd- RU.UNIX.BSD ------------------------------------------------------------------ From : Valentin Nechayev 2:5020/400 20 May 2002 22:29:45 To : Alexander V Naumochkin Subject : Re: ad(4) -------------------------------------------------------------------------------- >>> Alexander V. Naumochkin wrote: > Пусть лифтатор (чего ты, кстати, гениального в нём нарыл, моему скудному > умишке так и осталось не по силам просечь :) отсортировал очередь запросов. > Пусть. И влил их куда надо. Можно практически не сомневаться, что в > _большинстве_ случаев (напоминаю - я веду речь исключительно в контексте умных > дисков!) диску придётся этот список рубануть впополам и переставить половинки > местами (полагаю, что всем ясно, зачем :). И это - как минимум. А где рубить - > заранее неизвесто. Почему неизвестно? По адресу последнего отработанного запроса. > Значит, придётся дисковому думателю/анализатору пройтись-таки по > списку до (хотелось бы :) той самой точки рубления. Hо с "хотелось бы" > обломчие будет :) Вот ведь фигня какая - нет в спецификация на > программирование этих железяк требования, что бандлы запросов должны > поставляться строго отсортированными. И не знает диск, что ему "гениальный > лифтатор" подсунул упорядоченный список. А это значит, что дисковому > переставлятору запросов всё равно придётся просмотреть _весь_ список > (независимо от того, случится reordering или нет) до начала его исполнения. Что значит "просмотреть"? Запросы поступают по одному (даже если у тебя 8 процессоров - будет поступление по одному, потому что иначе не напишут). Запрос поступил - вставили в отсортированный список. > И > так далее, короче :) Вполне может быть, что именно потому и нет того > подниматора в исходниках FreeBSD до сих пор, что полезность его на > сколько-нибудь современных дисках весьма сомнительна... "Да, конечно" (c) ;))) По-моему, ты как-то слишком странно понимаешь этот алгоритм. Поверь, он немного другой;) Попытаюсь описать. Итак: у драйвера есть: - очередь запросов. очередь сортирована. хранятся адрес начала, конца очереди и текущего исполняемого элемента, если он есть. - текущий исполняемый элемент. - текущее направление движения - вперед/назад. Hе имеет смысла при пустой очереди. Действия функции помещения в очередь запросов: вставить в нужное место упорядоченного списка. Если текущего выполняемого нет (при этом очередь до добавления должна была быть пустой, иначе ошибка программирования), то толкнуть этот добавленный на выполнение. Действия обработчика прерывания по завершению операции: посмотреть, куда показывает флаг направления, и попытаться сместиться по этому направлению на следующий в списке блок. Если есть такой - толкнуть на выполнение. Если нет - поменять направление и начать с соотв. конца. Если список стал пустым - успокоиться. Фактически я обошелся, кажется, без запоминания номера последнего отработанного блока вне очереди - эта информация не нужна, если очередь пуста. У тебя мне непонятно, откуда взялась какая-то непонятная очередь запросов - "не было ни гроша, и вдруг алтын". Обычно бывает все-таки немного не так ;) > Вот и скажи теперь - так уж ли радужна картинка? Может, ну их на хер, те > умные устройства? Hазад, в каменный век - там-то всё контролируемо было, ума > не проявлял никто, кроме драйвера. Вода мокрее, трава зеленее, мужики > мордастее, бабы 3.1415926здастее :). А то учинили тут прогресс, блин :)) В каменном веке все было наоборот (tm) /netch --- ifmail v.2.15dev5 * Origin: Dark side of coredump (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix.bsd/73689967f79d.html, оценка из 5, голосов 10
|