Windows 7, ACPI и Power Plans
Внезапно обнаружил, что в Win7 системный (ID 4) процесс непрерывно отъедает около 12% процессорного времени. В ноутбуке MSI GT72S 6QE, с его большим запасом по охлаждению, это практически незаметно - изменение тона вентилятора было на пределе слышимости, а слух за долгое время привык к тому, что дебильные сайтописатели своим дебильным JS-кодом часто создают длительную нагрузку в 15-20% практически в любом браузере, отчего обороты вентилятора плавают постоянно.
Виновником повышенного потребления оказался драйвер ACPI (acpi.sys), несколько сот раз в секунду дергавший какие-то устройства. Это было видно в Process Explorer, однако в Win7 он не может открыть стеки системных потоков и показать вызовы. В Process Hacker стек открывается, но ничего вразумительного там навскидку не видно, при этом DrWeb начинает ругаться на "Tool.ProcessHacker" в памяти.
Гугление показывает, что проблеме уже почти двадцать лет (впервые на нее стали жаловаться в XP), но и поныне множество пользователей Win10 жалуется на то же самое. Рекомендации тоже не изменились: "протрите фары, попинайте колеса перегрузите систему, обновите драйверы и BIOS, поменяйте схему управления питанием, отключите какие-нибудь устройства...".
Сколько-нибудь определенного алгоритма поиска источника проблемы ни MS, ни умельцы так и не родили. Windows Performance Toolkit, весьма удобный для выявления источников кратковременных всплесков потребления, сумел показать только функции acpi.sys, которые нагружают процессор, но без параметров не понять, каким устройствам они адресованы.
С отчаяния перепробовал все найденные советы - и толковые, и откровенно дурацкие; безрезультатно. Попросил помощи у коллег - предложили только самостоятельно писать драйвер для перехвата вызовов в acpi.sys, затем добыть из ноутбука таблицы ACPI, и по ним определять устройства, с которыми работает виновник торжества. Увы, все это слишком затратно по времени. :(
Для начала решил посмотреть, что вообще есть в тех таблицах. В настройках HWiNFO, на странице Safety, есть параметр ACPI AML Enumeration, по умолчанию выключенный. Я его включил и запустил утилиту, а она в процессе сбора информации намертво подвесила систему. Выключив и включив ноутбук, я после перезагрузки обнаружил, что повышенное потребление исчезло. Настройки в BIOS и системе не изменились, ничего не испортилось, но acpi.sys перестал часто дергать устройства. Я так и не понял, в чем было дело. Хорошо, хоть время на копание в системе сэкономил. :)
Попутно разобрался со схемами управления питанием (Power Plans). Оказывается, в них больше половины скрытых настроек, отмеченных ненулевым значением (или ненулевым младшим разрядом) Attributes в дереве описания схем (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings). Для управления атрибутами описаний служит недокументированный ключ -attributes в PowerCfg, а единственным определенным атрибутом - это самое сокрытие (attrib_hide):
powercfg -attributes [] {+|-}attrib_hide
и - группа и элемент схемы, задаваемые GUID'ами или частично определенными идентификаторами, которые можно посмотреть командой PowerCfg -aliases. Для открывания параметра перед attrib_hide нужно поставить "-" (снять атрибут сокрытия).
В сети есть множество списков команд powercfg для снятия этих атрибутов, но все они являются "включающими" - то есть, там содержатся только известные авторам идентификаторы настроек. Чтобы заведомо открыть все имеющиеся в системе настройки, нужно править атрибуты вручную (непосредственно в RegEdit или через экспорт-импорт). Чтобы не париться, быстренько сваял батничек, который снимает атрибуты со всех настроек, зарегистрированных в системе. То есть, он будет работать для любых версий системы, пока не изменится сам принцип организации этих схем.
Попутно оказалось (я это давно подозревал, но не было времени проверить - возможно, это даже где-то описано), что штатной модификацией любой из стандартных схем не получить поведения, определяемого другой схемой, даже если все доступные параметры будут одинаковыми. Так получается потому, что в схемах есть параметр 245d8541-3943-4422-b025-13a784f679b7 (Power plan type), который по умолчанию скрыт вышеупомянутым атрибутом, отчего не отображается в результатах PowerCfg -query. Значения: 0 - power saver, 1 - high performance, 2 - balanced. Если его не изменить, то даже новая схема, унаследованная от одной из стандартных, будет задавать соответствующую политику, невзирая на явно заданные параметры.
Этот параметр не входит в какую-либо подгруппу, для доступа к нему используется фиктивный идентификатор подгруппы fea3413e-7e05-4911-9a71-700331f1c294 (sub_none), так что команда для его изменения будет выглядеть так:
powercfg -set{ac|dc}valueindex sub_none 245d8541-3943-4422-b025-13a784f679b7
где - GUID или идентификатор одной из стандартных схем (scheme_min - High Performance, scheme_max - Power Saver, scheme_balanced - Balanced), а - один из перечисленных выше типов (0..2).