OSDev

Привет всем.

Я ищу информацию, которая может помочь в оценке латентности прерываний на x86 процессорах. Очень полезная статья была найдена на "datasheets.chipdb.org/Intel/x86/386/technote/2153.pdf". Однако, эта статья открыла очень важный вопрос : как могут быть определены задержки создаваемые ожиданием процессора завершения выполняющейся на момент получения прерывания инструкции? Я имею ввиду задержки между распознаванием сигнала INTR и выполнением микро-кода INTR. Насколько я помню, Intel Software developer manual также говорит что-то об ожидании завершения выполнения текущей инструкции. Но также он говорит что-то о существовании прерываемых инструкций. Главный вопрос: как может быть определена максимальная продолжительность ожидания завершения инструкции для определенного процессора? Нужна оценка в тактах ядра ЦПУ, а не в секундах или микросекундах, и в количестве операций доступа к памяти (DMA и многопроцессорность могут быть проигнорированы). Промахи кэша и TLB и другие факторы влияющие на длительность задержки должны быть учтены.

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

Буду рад любой помощи. Если вы знаете какую-нибудь информацию, которая может быть полезна, то поделитесь ей, пожалуйста.

Точную информацию может дать только производитель, а он её, насколько знаю, не предоставляет. Самыми "долгоиграющими" непрерываемыми инструкциями будут, по всей вероятности, команды деления. Ускорение там возможно лишь путём деления не на 1 разряд за каждый такт, а на несколько (фактически -- выполнение деления не двоичной системе, а в четверичной, восьмеричной и т.д.), но при этом резко растёт объём оборудования, поэтому поделить сразу на 32 разряда не получится: делитель на кристалл не влезет :))) Понятно, что по тактам современные процессоры не хуже, чем первые (на самом деле лучше, но не обязательно за счёт деления как такового; выигрыш может достигаться за счёт вспомогательных операций типа предварительной выборки и декодирования самой команды, заблаговременного считывания её операндов и т.п.), так что можно было бы это взять за основу. 16-разрядная DIV с операндами-регистрами на 8086 выполялась за 165-184 такта; техническим пределом для "однобитового" деления является число разрядов делителя -- т.е. 32 при делении 64/32 и 64 при 128/64.

Я не думаю, что в Вашей задумке действительно важна столь высокая точность, так что можно было бы предположить, что допустимо использовать непрерываемые участки длиной до 100 тактов. И, кстати говоря, для применений реального времени важны задержки всё-таки в секундах, а не в тактах. Учитывая же тактовые частоты современных процессоров, задержки распространения сигналов запроса и подтверждения прерывания, вносимые как длинами линий, так и всякими электронными компонентами (контроллером прерываний, например), могут оказаться больше, чем собственно время, которое прерываниям придётся прождать, пока процессор их не разрешит.

Я параллельно тролю Intel относительно данного вопроса, но он пока несильно чешется.



Один из вариантов. Но есть еще инструкции FPU, которые тоже, вроде как должны обрабатывать атомарно. Операции работы с памятью, которые при пробое кэша и TLB могут опустить операцию деления ниже плинтуса. Есть еще очень подозрительные операции ввода-вывода работающие с портами.

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

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

Моя цель: попытаться реализовать работу с критическими секциями таким образом, что бы она не вызывала никаких задержек относительно гарантированного максимального времени ожидания определяемого процессором. Так чтобы латентность прерывания определялась как время приема прерывания процессором + время на путь от первой инструкции обработчика ядра ОС до первой инструкции user-defined ISR. А не как время приема прерывания процессором + (максимальной время ожидания выхода из критической секции - время приема прерывания процессором) + время на путь от первой инструкции обработчика ядра ОС до первой инструкции user-defined ISR.

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

Но в таком случае никакого разговора о системах реального времени быть не может. Ведь для них определяющей характеристикой является предсказуемость. То есть способность дать абсолютную гарантию, что прерывание поступившее на процессор, будет обработано не позднее чем через время Т. А так получается, что если процессор теоретически может находится в состоянии обращения к портам сверхмедленного устройства, скорость работы которого стремится к нулю, то время обработки прерывания будет стремиться к бесконечности. Какие гарантии по отклику в таком случае может дать разработчик ядра ОС?

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

Трудно предсказать. Проще всего померить. Обращение к портам может занимать тысячи тактов.
Самая медленная шина это ISA(LPC) 8МГц.
Самое плохое это SMM. Корректирует таймеры. Время задержки может быть до нескольких мс.


Интересно, а как это выглядит?

А наверно в многопроцессорной системе может возникнуть даже небольшая очередь к внешней шине - очередь из обращений к портам.

Должно быть, это называется стресс-тестом. Запускается сразу всё, что может запуститься, и оценивается результат.

Это все понятно, что при разработке системы реального времени, используются специальные специальные жестко определенные наборы программного и аппаратного обеспечения для которых известны их временные характеристики (в том числе и процессор). Но традиционно такие системы разрабатывают так, чтобы было относительно просто рассчитать время максимальной задержки. To есть должна быть какая-то формула, рассчитывающая общую задерку в обработке прерывания, на основании существующих данных предоставляемых производителем каждого компонента системы. Соответственно, должна быть какая-то формула или числовое значение определяющая засть задержки обеспечиваемую непосредственно процессором. То есть даже если мы создадим систему состоящую из идеальных компонентов предоставляющих нулевые задержки и реального процессора, то у нашей системы будет задержка в обработке прерывания, но вся эта задержка будет обеспечиваться исключительно процессором. Вот меня и интересует эта максимальная задержка. А лучше формула позволяющая оценить задержку в тактах, количестве обращений к памяти, к внешним устройствам. например Х = 48 тактов + 2 * простейший_доступ_ к_памяти.


Я об этом тоже думал. Но тут остается открытым вопрос: инструкции in\out - прерывные или не прерывные?


Как я уже упоминал выше. Каждый компонент в системе поставляется с характеристикой вносимой им задержки. Создавая систему учитывает задержки по наихудшему сценарию.


Да-да-да, все влият на задержку. доступ к памяти - это вообще отдельная тема. На него влияют собственно производительность шины процессор-память, стоимость промохов кэшей и TLB, DMA, SMP многопроцессорность. В общем - это совсем беда.

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