Сколько инструкций требуется ядру Linux для обработки прерывания на коре головного мозга A9?

Ваш вопрос связан с тем, как рассчитать прерывание задержка Linux. По крайней мере, вам может быть интересно, сколько времени потребуется, прежде чем ваше прерывание начнется. Мы проигнорируем этот аспект irqs здесь.

Простой способ - переключить GPIO и использовать осциллограф для измерения прерывания. Вы даже можете несколько раз переключать GPIO, чтобы увидеть, сколько времени занимают разные фазы. Эта ссылка Window CE показывает пример измерения задержки. Некоторые контроллеры прерываний (такие как IMX) имеют режимы мультиплексирования ввода/вывода, в которых номер прерывания будет повышать/понижать конкретную линию ввода/вывода. Кроме того, вы можете добавить код для переключения строки (подпрограммы см. ниже).

Исходный код основной обработки прерываний находится в entry-armv.S. Существуют макросы, определенные для используемого вами контроллера прерываний, и они зависят от файла .config. Например, существуют упреждающие прерывания, контроллеры множественных прерываний, SMP и т. д. основные векторы определяются в нижней части entry-armv.S. Общий смысл в том, что проверяется текущий режим работы, а затем берется либо __irq_usr, либо __irq_svc. Эти подпрограммы имеют разные преамплы для сохранения состояния, но обе они заканчиваются вызовом макроса irq_handler. В _irq_usr есть сведения о cmpxchg, но если вы укажете и ARM cortex в своем .config, это не будет применяться. Основное отличие будет заключаться в возможном переключении контекста после IRQ в пользовательском режиме. Ваша машина определяет mach/entry-macro.S, которые являются макросами ассемблера для доступа к контроллеру прерываний и получения номера прерывания. Затем он переходит к общему irq код обработки в каталоге kernel верхнего уровня.

Таким образом, второй способ - проверить код и вычислить его напрямую. Вероятно, это будет проще, если вы посмотрите на исходный код, скомпилируете ядро, а затем сделаете objdump --disassemble на образе vmlinux и найдёте эти символы. Вы увидите развернутый макрос irq_handler, и в конце концов он должен перейти к вашему коду IRQ.

Как видно из исходного кода, есть также TRACE_IRQFLAGS. Вы можете проверить, доступно ли это на Cortex A9, который вы используете с make menuconfig (и введите /TRACE_IRQFLAGS). Не знаю есть в наличии или нет.

Существуют такие вариации, как

1. Прерывание из режима User/SVC.
2. В настоящее время выполняется другое прерывание.
3. Прерванный код (например, stm/ldm) может занять некоторое время для завершения.
4. Ошибки страницы в вашем ISR. Некоторые драйверы Alsa могут давать сбои из-за нераспределенных страниц, по крайней мере, в некоторых версиях Linux.
5. Условные операторы в вашем ISR.

Измерение области действия покажет джиттер в IRQ обслуживании. Изучение инструкций обычно показывает, что IRQ может никогда не обслуживаться; например, если прерывания с более высоким приоритетом постоянно упреждают/предотвращают IRQ. Вероятно, вам нужно сделать и то, и другое, чтобы полностью оптимизировать работу в условиях жесткого дедлайна.

Часто вас не волнует, сколько времени занимает весь IRQ, но время между поднятием строки IRQ и записью/чтением некоторого периферийного регистра. Например, FIFO может иметь ограниченную глубину, и если задержка между IRQ и чтением регистра FIFO больше, чем FIFO_Size x BPS, то у вас проблемы с переполнением FIFO.

Инфраструктура FIQ намного быстрее, но возможности ядра, которые вы можете использовать, гораздо меньше!

Изменить: Cortex A9 Технический справочник содержит количество инструкций в приложении B. Большинство инструкций ARM представляют собой один цикл на большинстве архитектур, за исключением загрузки/сохранения памяти, кратных команд и ветвей. Следуйте 3-му и 4-му абзацам выше, чтобы найти полный путь инструкций для обработки прерывания Linux для вашей конфигурации, и просто добавьте его; для оценки (как задает исходный вопрос) вы можете просто подсчитать инструкции, поскольку они обычно представляют собой один цикл.

Хотя вы можете рассчитать теоретическое минимальное количество циклов ядра, изучив исходный код, фактически полученное число гораздо менее точно из-за влияния кэширования, производительности памяти и контроллера памяти, того, что другое ядро ​​делает в это время, и различных факторов. другие факторы, зависящие от микроархитектуры рассматриваемого процессора ARM.

Я подозреваю, что вам было бы лучше измерить фактическую производительность задержки прерывания вашей системы, используя либо цифровой осциллограф, либо счетчики производительности.

Конечно, для приложений жесткого реального времени вам необходимо знать наихудшую задержку прерывания, которая включает в себя наихудший случай всех этих факторов.