Куда девается многозадачность Windows при опросе CD дисковода?

Она много в чём не лучший показатель... А вообще, что в Винде, что в Линухе ядро перегружено тем, что можно было бы без проблем вынести за его пределы. И в первую очередь это как раз драйверы файловых систем и сетевых протоколов. Им с железом напрямую работать не требуется, так на кой ляд их в ядро пихать? Ради производительности? Так потери на переключение контекста мизерные по сравнению с общим временем выполнения операций ввода-вывода с этими устройствами.

В общем, на первом месте среди причин -- плохая архитектура и реализация оси.

 

Pavia

не похоже на бета релиз, последней бетке уже года два как прошло. С "кандидата" никаких проблем у нВидиа не замечал.
Чья вообще эта псевдостатистика? Где ты такое прочитал? Похоже на действия конкурентов...

 

у меня лично такое впечатление что как раз этого шага винда и не делает

 

ECk

Это объяснение мне больше всего нравится. Пока я цдром не вынес на отдельный, специально для этого приобретённый комп, и рипал аудио диски на своём десктопе под линём, у меня сложилось впечатление, что висеть всё начинает когда происходит обращение к жёсткому диску. Пока этого обращения нету висит только процесс cdparanoia, а вот стоит кому-нибудь попытаться прочитать с жёсткого диска, что-нибудь как сразу подвисает ядро.

ps. но это лишь впечатление, которое сложилось из наблюдений, которые систематичными назвать сложно.
pps. насчёт подвисания линя, в случае вставки цд в привод -- я не помню. По-моему, небыло такого. Сегодня на работе попробую проверить. Это я к тому, что если линь не тормозит при вставке диска, то тормоза венды в этой ситуации -- это личные тормоза венды, вызванные, скорее всего, чтением диска: венда ведь диск автоматически монтирует в vfs.

 

SII

В ситуации с цдромом проблема лежит ниже файловых систем и сетевых протоколов.

Код (Text):

1. cat /dev/cdrom >/dev/null

вызывает тормоза не хуже, чем чтение данных с этого /dev/cdrom сквозь файловую систему.
ps. вообще, это оффтоп, но вы всё время, говоря о проблемах монолитного ядра, забываете про существование дискового кэша. У меня, обычно, из полутора гигов оперативки около гига занято этим самым кешом. И в большинстве случаев* чтения, реального ввода/вывода не происходит. Процесс просит прочитать в буфер, переключается в ядро, vfs передаёт запрос конкретной fs, та выдаёт низлежащему драйверу блочного устройства список секторов, блочное же устройство вместо обращения к жёсткому диску, копирует данные из одного места оперативки в другое. После этого стек вызовов разматывается, и управление передаётся обратно процессу. Если же будет сделано так, как предлагаете вы, то вся эта операция будет выглядеть так же, только количество переключений между ядром и разными процессами увеличится раз в несколько.

*) Если вам интересно, я могу попробовать посчитать процент попаданий по этому кешу. Но, только, если вам очень интересно: это займёт часов несколько кодинга, и недоступности моего компа (который зеркалом генту в локалке служит) на время перезагрузок с модифицированным ядром. Лучше возьмите ядро линя, и займитесь профайлингом самостоятельно. Я, на самом деле, с громадным удовольствием увижу подтверждение/опровержение вашего мнения, если оно будет сопровождено цифрами.

 

Провел я маленький экспримент. Вставляю CD и сразу после этого выполняю:

char drive[100]="\\\\.\\E:";
hCD = CreateFile( drive, GENERIC_READ, FILE_SHARE_READ,NULL, OPEN_EXISTING, 0, NULL );

Хендл возвращается секунд этак через 5. Лишь после того как Винды разберутся, что за диск им подсунули.

 

насчет эффективности винды при обработке аппаратных прерываний
есть такое понятие - interrupt storm
это когда скорость дергания за ножку INT примерно равна скорости обработки
при этом как вы сами понимает компьютер мертво стоит, работает только хендлер
это частенько бывает на современном хардваре, ибо вся периферия упрощается
все делает ЦПУ - сменился статус -IRQ, пришел байт -IRQ, ушел байт -IRQ ...
это интел придумала и стала двигать еще десяток лет назад - вот пожынаем плоды типа

наблюдал эту штуку недавно на одном фирменном серваке супермикро с оптеронами
настоящий ДоС без шуток, а всего-то вставили флешку

 

вот стоит рядом старый комп без IDE - все сказёвое и диски и резак
там никаких задержек и тормозов, специально проверил

 

Gray

фишка не в том что хендл долго возвращается а в том что все эти 5 секунд винда мертвая

 

Ребята мне кажется проблема здесь в том, что ATAPI приводы не имеют аппаратной поддержки события "вставка-извлечение носителя." Я с этим столкнулся, когда писал для KolibriOS драйвер ISO9660 и соответствующую обвязку процедур непосредственно работающих с приводом позаимствовал у Кулакова. Всю процедуру обнаружения данного события пришлось реализовать методом периодического опроса нажатия кнопки извлечения диска, причем процедура тем сильнее загружает систему чем медленней комп, потому что для адекватной реакции приходится не реже чем 10 раз в секунду опрашивать. А без реализации этого реализация кэширования данных оказалась невозможной, по крайней мере для меня.
Возможно на некоторых новых моделях приводов этот недостаток уже устранен, но в стандартной реализации этого нету.
Как результата при вставке диска часть дисковой подсистемы отвечающей за ATAPI подвисает не менее чем на 15-45 секунд в зависимости от конкретной аппаратуры, но сама система работает нормально. Конечно если на одном шлейфе висит еще устройство, то оно будет недоступно - это физическое ограничение и с этим ничего не поделаешь.
И здесь надо учитывать что Виндовс дополнительно производит анализ диска на наличие содержимого, если отключить эту опцию то ситуация значительно улучшается. А в целом виноваты: кривые алгоритмы, кривые компиляторы, ленивые программисты.