Comments 12
Спасибо за статью, тема важная. Только написано, даже для людей в теме, заумно :) Чувствуется, что Вы хорошо понимаете то, о чем говорите, но текст нуждается в шлифовке. Обычно пишут много воды, а у Вас, наоборот, слишком кратко. И перебор с англицизмами.
Прошу прощения за критику, я из лучших побуждений :)
Прошу прощения за критику, я из лучших побуждений :)
Отчего же, правильная критика. Единственно, насчет англицизмов — сложно поддержать баланс между НГМД и FDD :). Возможно, я считаю неправильно, что Last Level Cache звучит привычнее, чем «кэш последнего уровня»?
В следующий раз напишу, как именно работает cache coloring (раскраска кэша?), с картинками. Надеюсь, кому-нибудь окажется полезно.
По моему тут у вас архитектурная проблема. ISR должна исполнится максимально быстро, потому никакого FIR фильтра в ней не должно быть. Она должна например принять даные и отсигналить, а уже приложение профильтрирует и передаст драйверу другого устройства.
Я в курсе. Конечно, это надо делать в DPC.
Я упростил пример, чтобы сконцентрироваться на том, что даже если исполняется код на самом верхнем IRQL, и некому его прерывать, то исполняться он все равно будет за разное время.
Кстати, если бы я использовал, например, Twincat под Windows XP, то FIR работал бы все равно фактически на 28 IRQL, а не на 2, как рекомендуете вы и Microsoft.
Я упростил пример, чтобы сконцентрироваться на том, что даже если исполняется код на самом верхнем IRQL, и некому его прерывать, то исполняться он все равно будет за разное время.
Кстати, если бы я использовал, например, Twincat под Windows XP, то FIR работал бы все равно фактически на 28 IRQL, а не на 2, как рекомендуете вы и Microsoft.
Я вообще никак не рекомендую.
Я под M8C, i8051, ARM библиотеки пишу. Самое большое преступление это делать какую-то работу в обработчике прерываний, в обработчике принял данные, передал кому нужно и вернул управление. Иначе пользователь вместо реакции на нажатие кнопки получит что система не реагирует и нажмёт второй раз например.
Я под M8C, i8051, ARM библиотеки пишу. Самое большое преступление это делать какую-то работу в обработчике прерываний, в обработчике принял данные, передал кому нужно и вернул управление. Иначе пользователь вместо реакции на нажатие кнопки получит что система не реагирует и нажмёт второй раз например.
Это действительно достаточно большое преступление в 99% случаев, когда пишется ISR. Еще бОльшее преступление — отдавать эту работу в DPC в остальных 1% случаях. Как и у остальных правил, бывают исключения.
Я специально указал в примере, что данные получены по DMA от одной железки, и результат работы FIR фильтра над ними обязательно должен быть отдан другой железке за минимальное и предсказуемое время. Как бы Вы еще поступлил на x86 под Windows или Linux?
Я специально указал в примере, что данные получены по DMA от одной железки, и результат работы FIR фильтра над ними обязательно должен быть отдан другой железке за минимальное и предсказуемое время. Как бы Вы еще поступлил на x86 под Windows или Linux?
А зачем тут вообще ОС?
Из пушки по насекомым, нет?
Из пушки по насекомым, нет?
«Это просто пример, и пусть в этом примере на машине одновременно исполняется масса другого нужного кода.» Например, GUI под Windows. Клиентам очень нравится.
Когда есть ОС, разработка сложных и больших вещей проще. А если было бы нужно просто гонять данные с минимальной обработкой, то ОС, конечно же, не нужна.
Когда есть ОС, разработка сложных и больших вещей проще. А если было бы нужно просто гонять данные с минимальной обработкой, то ОС, конечно же, не нужна.
Sign up to leave a comment.
Worst case execution time на x86