насколько быстро процессор может обрабатывать прерывания

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


operating-system processor architecture interrupt context-switch
person howtechstuffworks    schedule 30.09.2012    source источник
comment
Это так зависит от процессора. Вы можете посмотреть это: advenage.com/topics/linux-timer- частота прерывания.php   -  person James Black    schedule 30.09.2012

Ответы (2)


arrow_upward
2
arrow_downward

Насколько быстро зависит от нескольких факторов:

  1. задержки в аппаратной части ЦП и контроллера прерываний (если есть)
  2. тактовая частота процессора (часто события (или ответы на них) происходят не быстрее, чем это)
  3. скорость, с которой ЦП может получить доступ к необходимой памяти (системные таблицы (например, таблица векторов прерываний, но могут быть таблицы сегментов, таблицы страниц и другие), стек (указатель инструкции прерванного кода обычно сохраняется в стеке, так что ISR может вернуться к нему), сам код ISR и все данные, которые он использует). Очевидно, что код, данные и кэши TLB будут вносить свой вклад.
  4. время, необходимое ISR для выполнения своей работы, особенно если ISR не могут вытеснять друг друга, и поэтому параллельные прерывания должны быть сериализованы.
  5. приоритеты прерываний. Часто разным источникам прерываний присваиваются разные приоритеты. Например, вы хотите, чтобы немаскируемые прерывания, прерывания машинной проверки (в основном, прерывания, сообщающие о серьезных аппаратных проблемах) и прерывания таймера имели более высокий приоритет, чем, скажем, прерывания клавиатуры. При обработке прерываний на основе приоритета все прерывания, чей приоритет ниже, чем обслуживаемое в данный момент прерывание, должны будут «ждать». Таким образом, если у вас много прерываний с высоким приоритетом, прерывания с более низким приоритетом могут обслуживаться с заметной и переменной задержкой. Крайним случаем будет бесконечное количество прерываний с высоким приоритетом. Это может быть связано с неправильной конструкцией или неисправностью оборудования.
  6. связь и взаимодействие с другими процессорами. В системах MP обработчики прерываний могут иногда использовать спин-блокировки, чтобы получить эксклюзивный доступ к ресурсу, совместно используемому несколькими процессорами. Если есть конфликт, ISR будет ждать, и все другие прерывания (или все прерывания с более низким приоритетом) не будут обслуживаться, пока текущий ISR не завершит свою работу.

Это общий ответ на общий вопрос.

EDIT: я забыл упомянуть еще одну вещь. Существуют некоторые странные ЦП, в которых определенные инструкции повторяемы (вспомните rep movsb в x86), и прерывания не могут начать обслуживаться до тех пор, пока повторяющаяся инструкция полностью не завершится, что может занять время, эквивалентное выполнению 1000 или даже более простых отдельных инструкций. Таким образом, несмотря на то, что прерывания разрешены, могут быть некоторые причуды ЦП, не позволяющие начать работу ISR. Одним из таких процессоров является TMS320C54xx от TI. С ним вы должны быть осторожны с кодом КИХ-фильтра. Если фильтр длинный и реализован как повторяющаяся инструкция MAC, это приведет к задержке в обслуживании прерывания.

person Alexey Frunze    schedule 30.09.2012

arrow_upward
0
arrow_downward

В обычной Linux-системе есть значение nice , а более низкие значения nice имеют типичное значение кванта 800 мс, а более высокое значение nice имеет квант 5 мс.

Система Linux использует эвристику, чтобы решить, является ли процесс интерактивным или нет. Вы лучше прочитайте эту заметку:

https://www.cs.columbia.edu/~smb/classes/s06-4118/l13.pdf

Существует несколько структур данных, которые касаются планировщика, например, linux отслеживает количество интерактивных процессов, ожидающих привязки ввода-вывода и т. д. и т. д.

В Windows больше, чем упреждающая многозадачность, прикладные программы поддерживают ядро ​​​​через вызов API GetMessage() [в случае программ с графическим интерфейсом Windows]. Когда вы вызываете GetMessage() , этот процесс будет запланирован назад, когда есть сообщение, ожидающее отправки. обрабатываться в его системной очереди.

person sandun dhammika    schedule 30.09.2012