Раньше никогда не задумывался, считая очевидным запрет сабжа в ядре и долго принимал это как аксиому. Щас ради интереса зачитался что-то IRQL_Thread.doc с microsoft.com и нашел фразу про то, что можно, а что нельзя при irql==2: Вот меня интересует, почему нельзя было опционально сделать, например, по вызову какой-нибудь API, синхронную загрузку с диска при IRQL=2. Да, придется всем потокам подождать, пока операция чтения не будет завершена. Но ведь это не так критично, все равно большую часть времени множество потоков системы простаивают (если посмотреть CPU TIME процесса System Idle, то оно обычно составляет более 99% от аптайма). Какие у вас есть мысли по этому поводу?
Вспомнил, что часть кода самого менеджера памяти работает на Dispatch. Но все равно можно было аккуратно сделать синхронизацию этой байды и/или оставить на страх и риск девелопера...
Это у тебя дома простаивает, ты не сервера нормальные посмотри А ядро-то одно. Есть ещё мысли, но несформулированные по-людски.
Ну все равно долго ждать то не надо. Тем более что половина из всех "выгруженных" страниц реально висят в списке простаивающих/модифицированных, имея Transition PTE, и чтобы загрузить которые ВООБЩЕ не нужно обращаться к диску - лишь подправить PTE и списки MMPFN. Тут я вообще не вижу никакой разумной причины.
Great За то время, пока подкачивается одна страница, процессор успеет выполнить десятки тысяч команд, а то и больше. Так что "простаивать" можно разве что офисной ОС, где критичность задержек фактически определяется скоростью реакции человека. Во всех остальных случаях простаивать нельзя.
Ога, совсем чуть-чуть Код (Text): item time scaled time in human terms (2 billion times slower) -------------------------------------------------------------------------------------------- processor cycle 0.5 ns (2 GHz) 1 second cache access 1 ns (1 GHz) 2 seconds memory access 15 ns 30 seconds context switch 5,000 ns (5 ms) 167 minutes disk access 7,000,000 ns (7 ms) 162 days quantum 100,000,000 ns (100 ms) 6.3 years Если нужно не бсодить при страничных промахах,то понижай IRQL, а то так и обработчику таймера тоже можно будет фаулты генерить - адски шустрая система получится %)
да ну?) будет более безотказно? =)) SII ну хорошо, допустим, но почему нельзя опционально было сделать?)
Ладно, в принципе я забыл что есть не-десктоп компы и где ожидание неприемлимо такое =) Так что вообщем-то вопрос снят.. хотя реализовать подобное я все равно попорбую)))
nester7 Ошибочка: переключение контекста -- микросекунды, а доступ к дистку -- миллисекунды. Латинскими буквами не обозначишь, лучше русскими (мкс и мс соответственно). Great А это зависит от кривизны проекта системы в целом и от кривизны рук тех, кто этот проект воплощает в металле... то есть в исходных текстах на каком-либо языке. Сделать безотказно можно. Винда создавалась не только для тех применений, где тормоза совершенно некритичны, а поэтому она не должна тормозить никогда. Правда, ей это не слишком хорошо удаётся, но ничуть не хуже, чем линуху (ни та, ни другая в нормальные ОСРВ не годятся совершенно).
Кхе, понижение IRQL ниже того уровня, на котором вызывается функция, зависит от кривизны проекта? По-моему, это гарантированно нестабильно
