Объекты управления включают объекты-примитивы для потоков, прерываний, таймеров, синхронизации, профилирования, а также два специальных объекта для реализации DPC и APC. Объекты DPC (Deferred Procedure Call - отложенный вызов процедуры) используются для уменьшения времени выполнения ISR (Interrupt Service Routines - процедура обслуживания прерываний), которая запускается по прерыванию от устройства. Ограничение времени, затрачиваемого на ISR-процедуры, сокращает шансы утраты прерывания.
Оборудование системы присваивает прерываниям аппаратный уровень приоритета. Процессор также связывает уровень приоритета с выполняемой им работой. Процессор реагирует только на те прерывания, которые имеют более высокий приоритет, чем используемый им в данный момент. Нормальный уровень приоритета (в том числе уровень приоритета всего пользовательского режима) - это 0. Прерывания устройств происходят с уровнем 3 или более высоким, а ISR для прерывания устройства обычно выполняется с тем же уровнем приоритета, что и прерывание (чтобы другие менее важные прерывания не происходили при обработке более важного прерывания).
Если ISR выполняется слишком долго, то обслуживание прерываний более низкого приоритета будет отложено, что, возможно, приведет к потере данных или замедлит ввод-вывод системы. В любой момент времени может выполняться несколько ISR, при этом каждая последующая ISR будет возникать от прерываний со все более высоким уровнем приоритета.
Для уменьшения времени обработки ISR выполняются только критические операции, такие как запись результатов операций ввода-вывода и повторная инициализация устройства. Дальнейшая обработка прерывания откладывается до тех пор, пока уровень приоритета процессора не снизится и не перестанет блокировать обслуживание других прерываний. Объект DPC используется для представления подлежащей выполнению работы, а ISR вызывает уровень ядра для того, чтобы поставить DPC в список DPC конкретного процессора. Если DPC является первым в списке, то ядро регистрирует специальный аппаратный запрос на прерывание процессора с уровнем 2 (на котором NT вызывает уровень DISPATCH). Когда завершается последняя из существующих ISR, уровень прерывания процессора падает ниже 2, и это разблокирует прерывание для обработки DPC. ISR для прерывания DPC обработает каждый из объектов DPC (которые ядро поставило в очередь).
Методика использования программных прерываний для откладывания обработки прерываний является признанным методом уменьшения латентности ISR. UNIX и другие системы начали использовать отложенную обработку в 1970-х годах (для того, чтобы справиться с медленным оборудованием и ограниченным размером буферов последовательных подключений к терминалам). ISR получала от оборудования символы и ставила их в очередь. После того как вся обработка прерываний высшего уровня была закончена, программное прерывание запускало ISR с низким приоритетом для обработки символов (например, для реализации возврата курсора на одну позицию - для этого на терминал посылался управляющий символ для стирания последнего отображенного символа, и курсор перемещался назад).
Аналогичным примером в современной системе Windows может служить клавиатура. После нажатия клавиши клавиатурная ISR читает из регистра код клавиши, а затем опять разрешает клавиатурное прерывание, но не делает обработку клавиши немедленно. Вместо этого она использует DPC для постановки обработки кода клавиши в очередь (до того момента, пока все подлежащие обработке прерывания устройства не будут отработаны).
Поскольку DPC работают на уровне 2, они не мешают выполнению ISR для устройств, но мешают выполняться любым потокам до тех пор, пока все поставленные в очередь DPC не завершатся и уровень приоритета процессора не упадет ниже 2. Драйверы устройств и система не должны слишком долго выполнять ISR или DPC. Поскольку потокам не разрешается выполняться, то ISR и DPC могут сделать систему медлительной и породить сбои при проигрывании музыки (затормаживая те потоки, которые пишут музыку из буфера в звуковое устройство). Другой частый случай использования DPC - это выполнение процедур по прерыванию таймера. Во избежание блокирования потоков события таймера (которые должны выполняться продолжительное время) должны ставить в очередь запросы к пулу рабочих потоков (который ядро поддерживает для фоновой работы).
Обработка прерываний таймера
Каждый компьютер имеет аппаратный таймер или системные часы, которые генерируют аппаратное прерывание через фиксированные интервалы времени. Временной интервал между соседними прерываниями называется тиком процессора или просто тиком (CPU tick, clock tick). Как правило, системный таймер поддерживает несколько значений тиков, но в UNIX это значение обычно устанавливается равным 10 миллисекундам, хотя это значение может отличаться для различных версий операционной системы. Большинство систем хранят это значение в константе HZ, которая определена в файле заголовков
Обработчик прерываний ядра вызывается аппаратным прерыванием таймера, приоритет которого обычно самый высокий. Таким образом, обработка прерывания должна занимать минимальное количество времени. В общем случае, обработчик решает следующие задачи:
1. Обновление статистики использования процессора для текущего процесса
2. Выполнение ряда функций, связанных с планированием процессов, например пересчет приоритетов и проверку истечения временного кванта для процесса
3. Проверка превышения процессорной квоты для данного процесса и отправка этому процессу сигнала SIGXCPU в случае превышения
4. Обновление системного времени (времени дня) и других связанных с ним таймеров
5. Обработка отложенных вызовов
6. Обработка алармов
7. Пробуждение в случае необходимости системных процессов, например диспетчера страниц и свопера
Часть задач не требует выполнения на каждом тике. Большинство систем вводят нотацию главного тика (major tick), который происходит каждые тиков, где зависит от конкретной версии системы. Определенный набор функций выполняется только на главных тиках. Например, производит пересчет приоритетов каждые 4 тика, a SVR4 обрабатывает и производит пробуждение системных процессов раз в секунду МакКузик М. К., Невилл-Нил Дж. В. FreeBSD: архитектура и реализация. -- М.: КУДИЦ-ОБРАЗ, 2006. -- 800 с...
Отложенные вызовы
Отложенный вызов определяет функцию, вызов которой будет произведен ядром системы через некоторое время. Например, в SVR4 любая подсистема ядра может зарегистрировать отложенный вызов следующим образом:
int co_ID = timeout(void (*fn)(), caddr_t arg, long delta)
где fn определяет адрес функции, которую необходимо вызвать, при этом ей будет передан аргумент arg, а сам вызов будет произведен через delta тиков. Ядро производит вызов fn() в системном контексте, таким образом функция отложенного вызова не должна обращаться к адресному пространству текущего процесса (поскольку не имеет к нему отношения), а также не должна переходить в состояние сна.
Отложенные вызовы применяются для выполнения многих функций, например:
1. Выполнение ряда функций планировщика и подсистемы управления памятью.
2. Выполнение ряда функций драйверов устройств для событий, вероятность ненаступления которых относительно велика. Примером может служить модуль протокола TCP, реализующий таким образом повторную передачу сетевых пакетов по таймауту.
3. Опрос устройств, не поддерживающих прерывания.
Заметим, что функции отложенных вызовов выполняются в системном контексте, а не в контексте прерывания. Вызов этих функций выполняется не обработчиком прерывания таймера, а отдельным обработчиком отложенных вызовов, который запускается после обработки прерывания таймера. При обработке прерывания таймера система проверяет необходимость запуска тех или иных функций отложенного вызова и устанавливает соответствующий флаг для них. В свою очередь обработчик отложенных вызовов проверяет флаги и запускает необходимые в системном контексте МакКузик М. К., Невилл-Нил Дж. В. FreeBSD: архитектура и реализация. -- М.: КУДИЦ-ОБРАЗ, 2006. -- 800 с...
Контекст процесса
Контекст процесса включает в себя содержимое адресного пространства задачи, выделенного процессу, а также содержимое относящихся к процессу аппаратных регистров и структур данных ядра. С формальной точки зрения, контекст процесса объединяет в себе пользовательский контекст, регистровый контекст и системный контекст.
Пользовательский контекст состоит из команд и данных процесса, стека задачи и содержимого совместно используемого пространства памяти в виртуальных адресах процесса. Те части виртуального адресного пространства процесса, которые периодически отсутствуют в оперативной памяти вследствие выгрузки или замещения страниц, также включаются в пользовательский контекст.
Регистровый контекст состоит из следующих компонент:
1. Счетчика команд, указывающего адрес следующей команды, которую будет выполнять центральный процессор; этот адрес является виртуальным адресом внутри пространства ядра или пространства задачи.
2. Регистра состояния процессора (PS), который указывает аппаратный статус машины по отношению к процессу. Регистр PS, например, обычно содержит подполя, которые указывают, является ли результат последних вычислений нулевым, положительным или отрицательным, переполнен ли регистр с установкой бита переноса и т. д. Операции, влияющие на установку регистра PS, выполняются для отдельного процесса, потому-то в регистре PS и содержится аппаратный статус машины по отношению к процессу. В других имеющих важное значение подполях регистра PS указывается текущий уровень прерывания процессора, а также текущий и предыдущий режимы выполнения процесса (режим ядра/задачи). По значению подполя текущего режима выполнения процесса устанавливается, может ли процесс выполнять привилегированные команды и обращаться к адресному пространству ядра.
3. Указателя вершины стека, в котором содержится адрес следующего элемента стека ядра или стека задачи, в соответствии с режимом выполнения процесса. В зависимости от архитектуры машины указатель вершины стека показывает на следующий свободный элемент стека или на последний используемый элемент. От архитектуры машины также зависит направление увеличения стека (к старшим или младшим адресам), но для нас сейчас эти вопросы несущественны.
4. Регистров общего назначения, в которых содержится информация, сгенерированная процессом во время его выполнения.
Системный контекст процесса имеет «статическую часть» (первые три элемента в нижеследующем списке) и «динамическую часть» (последние два элемента). На протяжении всего времени выполнения процесс постоянно располагает одной статической частью системного контекста, но может иметь переменное число динамических частей. Динамическую часть системного контекста можно представить в виде стека, элементами которого являются контекстные уровни, которые помещаются в стек ядром или выталкиваются из стека при наступлении различных событий. Системный контекст включает в себя следующие компоненты:
1. Запись в таблице процессов, описывающая состояние процесса (раздел 6.1) и содержащая различную управляющую информацию, к которой ядро всегда может обратиться.
2. Часть адресного пространства задачи, выделенная процессу, где хранится управляющая информация о процессе, доступная только в контексте процесса. Общие управляющие параметры, такие как приоритет процесса, хранятся в таблице процессов, поскольку обращение к ним должно производиться за пределами контекста процесса.
3. Записи частной таблицы областей процесса, общие таблицы областей и таблицы страниц, необходимые для преобразования виртуальных адресов в физические, в связи с чем в них описываются области команд, данных, стека и другие области, принадлежащие процессу. Если несколько процессов совместно используют общие области, эти области входят составной частью в контекст каждого процесса, поскольку каждый процесс работает с этими областями независимо от других процессов. В задачи управления памятью входит идентификация участков виртуального адресного пространства процесса, не являющихся резидентными в памяти.
4. Стек ядра, в котором хранятся записи процедур ядра, если процесс выполняется в режиме ядра. Несмотря на то, что все процессы пользуются одними и теми же программами ядра, каждый из них имеет свою собственную копию стека ядра для хранения индивидуальных обращений к функциям ядра. Пусть, например, один процесс вызывает функцию creat и приостанавливается в ожидании назначения нового индекса, а другой процесс вызывает функцию read и приостанавливается в ожидании завершения передачи данных с диска в память. Оба процесса обращаются к функциям ядра и у каждого из них имеется в наличии отдельный стек, в котором хранится последовательность выполненных обращений. Ядро должно иметь возможность восстанавливать содержимое стека ядра и положение указателя вершины стека для того, чтобы возобновлять выполнение процесса в режиме ядра. В различных системах стек ядра часто располагается в пространстве процесса, однако этот стек является логически-независимым и, таким образом, может помещаться в самостоятельной области памяти. Когда процесс выполняется в режиме задачи, соответствующий ему стек ядра пуст.
5. Динамическая часть системного контекста процесса, состоящая из нескольких уровней и имеющая вид стека, который освобождается от элементов в порядке, обратном порядку их поступления. На каждом уровне системного контекста содержится информация, необходимая для восстановления предыдущего уровня и включающая в себя регистровый контекст предыдущего уровня.
Ядро помещает контекстный уровень в стек при возникновении прерывания, при обращении к системной функции или при переключении контекста процесса. Контекстный уровень выталкивается из стека после завершения обработки прерывания, при возврате процесса в режим задачи после выполнения системной функции, или при переключении контекста. Таким образом, переключение контекста влечет за собой как помещение контекстного уровня в стек, так и извлечение уровня из стека: ядро помещает в стек контекстный уровень старого процесса, а извлекает из стека контекстный уровень нового процесса. Информация, необходимая для восстановления текущего контекстного уровня, хранится в записи таблицы процессов Робачевский А. М. Операционная система UNIX. -- СПб.: БХВ- Петербург, 2002. -- 528 с. .
Процессор перегружен? Виноваты системные прерывания.
Виной тому, что процессор перегружен практически в течение всего сеанса, могут быть так называемые системные прерывания, а это, в свою очередь, означает, что проблема кроется в области установленного на компьютере оборудования или драйверах для этих устройств. Но предупреждаю сразу: даже объёма всей этой статьи не хватит, чтобы вычленить все причины (и тем более варианты их решений) почему системные прерывания просто убивают Windows. Ибо подход к поиску проблем усложняется использованием куда более сложного инструмента, чем тот, что описывается здесь.
Что такое системные прерывания и как попробовать справиться с перегрузкой процессора?
Системные прерывания появляются в Диспетчере задач в качестве системного процесса, однако по сути они таковым не являются. Эта « » носит лишь репрезентативный характер, отображая загруженность процессора при работе с прерываниями на низком уровне. Она – неотъемлемая часть Windows, убить процесс нельзя. Несмотря на зловещее название, системные прерывания – обязательная и нормальная часть процесса взаимодействия ЦПУ и остального оборудования.
Причиной прерываний (точнее, слишком медленной время от времени работы) могут служить девайсы внутри вашего компьютера, установленные программы, а иногда и сам процессор. Ведь системные прерывания – есть некая форма взаимодействия между программой/«железом» и самим процессором. Всякий раз, когда новому процессу нужно появиться в системе, процессор бросает все дела и выполняет задачу. Неважно, нажал ли пользователь мышку или процесс запущен по расписанию, задача сразу добавляется в очередь на исполнение. По её выполнению процессор возвращается к предыдущему состоянию.
Как понимаете, системные прерывания вполне могут сигнализировать системе и пользователю, что в данный момент некоторые вычисления идут с ошибкой, что и выражается в серьёзных потреблениях ресурсов процессора этим «процессом». В здоровой системе системные прерывания «потребляют» НЕ БОЛЕЕ 2% от общего объёма работы процессора. Хотя мне встречались и процессоры с показателем прерывания от 3 до 10 %% – всё зависит от конфигурации. Но если вы заметили, что процессор тратит на прерывания хотя бы 5 – 10 %% от своей вычислительной мощности от сеанса к сеансу, это сигнал того, что у компьютера проблемы.
Системные прерывания. Как бороться с высокими показаниями?
Каждый из следующих шагов потребует перезагрузки системы. Не потому что так принято, а потому проблемы с прерываниями решаются часто простым перезапуском Windows.
ДРАЙВЕРЫ И ЕЩЁ РАЗ ДРАЙВЕРЫ
Самое первое средство, которое поможет определить, виноваты ли битые драйверы в том, что системные прерывания нагружают процессор, это немецкая утилита DPC Latency Checker . Скачайте её по этой ссылке:
Установки не потребуется. Суть утилиты проста. Запускаем и начинаем работу в Windows до тех пор, пока системные прерывания не начнут нам мешать. Вот окно нормально работающей сборки:
А вот они начинают себя проявлять:
Утилита в поле комментария на английском языке советует вам перейти в Диспетчер устройств и приступить к поэтапному отключению сетевых устройств, звуковых карт, USB контроллеров, устройств bluetooth . Советую прислушаться. После каждого отключения всматривайтесь в Диспетчер задач и окно утилиты, посмотрите, как система реагирует на временное отключение оборудования. Продолжите отключением всех внешних устройств: модемы, внешние диски, флешки. И если в какой-то момент наметятся изменения к лучшему, примите решение об обновлении драйвера к устройству. Но чтобы не было проблем с запуском Windows, вот эти устройства лучше не отключать (эти драйверы жизненно необходимы, но это тоже драйверы, и вполне возможно придётся переустановить дрова на материнскую всем пакетом как при установке Windows начисто):
На такой же манер действует и программа LatencyMon
http://www.resplendence.com/downloadsОна потребует установки, зато также бесплатна. Её задача – поиск файлов драйверов с высоким показателем вычислений, потраченных на отложенный вызов процедуры (процесса, который вызывается процедурой обработки прерывания в ответ на само прерывание, но необязательно сразу же исполняется). За этим мудрёным названием скрывается процесс поиска драйверов, в файлах которых хранится информация о том, что драйвер слишком много требует от процессора для обслуживания своего, приписанного конкретно ему устройства. Вот страница издателей:
http://www.resplendence.com/latencymonна которой, впрочем, я своими слепыми глазами ссылки для скачивания не нашёл, а потому представлю вам возможность скачать программу с моего сайта
СКАЧАТЬ БЕСПЛАТНО ПРОГРАММУ
Запустившись, та сразу сообщила мне о возможных проблемах с DVD приводом – драйвер atapi.sys отвечает именно за него (а кстати, привод не работает уже почти 3 месяца…) . Предупреждает, что возможно потребуется перепрошить BIOS:
Переходим во вкладку Drivers и отсортируем их по наиболее уязвимым показаниям, нажав на колонку DPC count :
К первым в строчке присмотритесь: они и могут быть причиной ваших проблем.
ВСЁ ПРОИЗОШЛО КАК-ТО ВДРУГ, ПОСЛЕ ПЕРЕЗАГРУЗКИ
Был один момент, когда ну никак не удавалось вычленить причину тормозов. Помог случай: пользователь “хапнул” вирус, который совершенно уничтожил DirectX, причём действовал крайне избирательно, убивая именно системные файлы Windows, оставляя DirectX игровые . Пришлось ремонтировать систему обновлением, и – о чудо! – вместе с дрянью пропали и системные прерывания. Я не пожалел немного времени, но результат оказался неожиданный. Виновниками оказались не вирусы и не драйверы, а пакеты обновлений. Вот их имена:
- KB3199986
- KB4013418
- KB3211320
Я настаиваю, что именно ПОСЛЕ УСТАНОВКИ ИМЕННО ЭТИХ ОБНОВЛЕНИЙ конкретный пользователь начинал мучиться от перегрузки системными прерываниями. Как-то так… вам информация к размышлению.
ИСКЛЮЧАЕМ НЕИСПРАВНОЕ ОБОРУДОВАНИЕ
Тоже может послужить причиной того, что системные прерывания нагружают процессор донельзя. Приступайте к проверке, если предыдущий поиск битых драйверов успеха не принёс. А поможет вам в поиске проблем с “железом” сама Windows и встроенные утилиты самодиагностики. О них я писал уже в статье . Пробегите глазами, информация окажется полезной, не сомневайтесь. Знайте – отошедшие от разъёма шлейфа также могут быть виновниками злоключений. Я лично сталкивался с проблемами и перегрева процессора, и “забывчивости” про-апгрейдить BIOS для новенькой Windows 10 (об этом ниже) – везде итогом были заметные системные прерывания.
ПРИМЕЧАНИЕ . Если системные прерывания одолели ваш ноутбук, вам придётся убедиться, что у вас нет проблем с умирающим аккумулятором. Прочтите статью, собственными силами.
ПРОВЕРЬТЕ ЗВУКОВУЮ СХЕМУ WINDOWS
Собственно, речь идёт о том, чтобы сбросить звуковые эффекты в Windows до установленных по умолчанию. Щёлкните по иконке звука правой мышкой и нажмите на Устройства воспроизведения :
Во вкладке Воспроизведение щёлкните два раза по пункту дефолтных устройств (у меня Динамики ), пройдите во вкладку Дополнительные возможности и установите галочку напротив Отключить все эффекты . Применить – ОК. Перезагружаемся и проверяем:
- ВИНОВАТА BIOS ?
Не исключено. BIOS – первая программа, которая запускается после нажатия на кнопку включения компьютера. Так что время проверить обновления для вашей BIOS. А чтобы поиски нужной версии не затягивались во времени, проверьте версию вашей BIOS прямо сейчас. В консоли команд cmd наберите последовательно две команды:
Systeminfo | findstr /I /c:bios wmic bios get manufacturer, smbiosbiosversion
I в первой команде – это большая латинская i .
Причина в жёстком диске?
“Вполне себе и даже очень”. Самый простой способ – проверьте диск на ошибки с помощью встроенных средств типа chkdsk . Если после “прогона” системные прерывания поутихли, причина обнаружена. Однако в случае, когда проблема появляется вновь и вновь, при всём том chkdsk неизменно обнаруживает ошибки, у вас проблемы (с жёстким, БП или материнской платой) – готовьтесь к худшему.
P.S. Ну, судя по отзывам проблема народ теребит. Обещаю тему развить в следующих статьях.
Успехов вам.
Прочитано: 1 238