Оптимизация приложений Windows* 8 для режима Connected Standby

Загрузить статью

Optimizing Windows* 8 Applications for Connected Standby [Eng., PDF 1.4MB]

Аннотация

В данной статье описывается проверка и анализ поведения приложений Windows 8 * в режиме Connected Standby. Поддержка этого режима является одним из требований Microsoft * WHQL для Windows 8 [1]. Поясняется, как выявить приложения, расходующие слишком много электроэнергии в режиме Connected Standby, и как устранить эту проблему. Этот документ предназначен для разработчиков программного обеспечения, изготовителей оборудования и технических пользователей.

Введение

Режим Connected Standby позволяет системе получать обновления и оставаться на связи при наличии любых сетевых подключений. Этот режим аналогичен принципу работы сотовых телефонов: телефон остается подключенным к сотовой сети, даже если его экран выключен. Подобным образом и приложения Windows 8, поддерживающие режим Connected Standby, запускаются в обновленном состоянии сразу после перехода в активный режим. Дополнительные сведения о режиме Connected Standby на ПК см. на сайте Microsoft [1].

При выключении экрана на всех системах, поддерживающих режим Connected Standby, все запущенные программы (включая и приложения, и ОС) начинают работать в соответствии с новым набором ограничений. Средство Windows Desktop Activity Moderator (DAM) отключает выполнение устаревших приложений, действуя аналогично режиму сна. Для этого выполняется приостановка всех приложений пользовательского сеанса и регулированиевсех сторонних служб. Эти меры позволяют добиться предсказуемого расхода электроэнергии на время бездействия. Это дает возможность системам, поддерживающим режим Connected Standby, свести к минимуму использование ресурсов и долго работать от аккумулятора. При этом приложения Windows 8 смогут поддерживать нужные возможности подключения. Кроме того, при повышении чувствительности аппаратных состояний питания программные службы должны правильно работать, чтобы не пробуждать систему без необходимости, так как при этом будет израсходована дополнительная энергия.

В оставшейся данной статьи описываются средства и методики для понимания поведения системы в режиме Connected Standby. Затем приведены два примера приложений, работу которых в этом режиме можно оптимизировать.

Средства

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

Windows PowerCfg

Windows PowerCfg — это программа командной строки для управления параметрами электропитания. Эта программа применяет трассировку событий Windows (ETW) для создания профилей систем. Пользователи могут запускать Windows Powercfg для просмотра и изменения планов и параметров электропитания, например времени сна, таймера пробуждения и схем электропитания. Если запустить Powercfg с параметром -energy, будет проведен анализ основных проблем энергоэффективности и работы от аккумулятора: изменения параметров таймеров платформы, изменения таймеров процессами и библиотеками приложений, использование ЦП каждым процессом. При использовании этого параметра также будет проверено, поддерживает ли система режим Connected Standby; будут перечислены параметры управления энергопотреблением оборудования и ОС. Для запуска Windows Powercfg требуются права администратора.

Два параметра командной строки используются для проверки и получения информации о поведении в режиме Connected Standby:

Powercfg –a: Этот параметр выводит все доступные состояния сна системы. Чтобы выполнить эту команду, откройте в Windows командную строку. В командной строке введите: % powercfg –a

Система, поддерживающая режим Connected Standby, сообщит о поддерживаемых состояниях сна, одним из которых будет этот режим. На рис. 1 показаны выходные данные команды powercfg –a для системы, поддерживающей режим Connected Standby.

Рисунок 1. Powercfg -a output

Powercfg -batteryreport

Параметр -batteryreport предоставляет информацию о поддержке режима Connected Standby и другие связанные данные. Создается отчет (в формате HTML) о статистике работы системы от аккумулятора путем сбора профиля на основе постоянно запущенной встроенной трассировки системы. Этот отчет содержит сводные данные об установленном аккумуляторе, версии BIOS, поддержке режима Connected Standby, а также о сроке работы от аккумулятора на основе фактического использования системы. На рис. 2 показан пример выходных данных команды с параметром -batteryreport, если ПК поддерживает режим Connected Standby.

Рисунок 2. Отчет о состоянии аккумулятора с поддержкой режима Connected Standby

В отчете также указывается использование аккумулятора в активном состоянии, в приостановленном состоянии и в режиме Connected Standby, как показано на рис. 3.

Рисунок 3. Использование аккумулятора в различных состояниях

Дополнительные сведения о решении Windows Powercfg см. на Microsoft website [2].

Microsoft Windows Performance Analyzer

Средство Windows Performance Analyzer (WPA), также известное под названием xperf, представляет собой набор инструментов мониторинга для составления подробных профилей производительности и электропитания Microsoft Windows и приложений. WPA удобно использовать для устранения проблем с утечкой энергии.

Перед переходом к примерам давайте разберемся с терминологией WPA. Вот определения основных терминов и названий столбцов WPA, взятые из документации System Internals, находящейся по адресу [3]:

Ready Thread:поток в готовом состоянии, ожидающий выполнения или готовый к переключению после завершения ожидания. При поиске потоков для выполнения диспетчер рассматривает только пул потоков в готовом состоянии.
Standby: поток в ждущем режиме, выбранный для последующего запуска на определенном процессоре. При возникновении подходящих условий диспетчер выполняет переключение контекста к этому потоку. Только один поток может быть в ждущем режиме для каждого процессора в системе. Обратите внимание, что поток может быть выгружен из ждущего состояния еще перед выполнением (например, если поток с более высоким приоритетом запускается перед началом выполнения ждущего потока).
Waiting: поток может перейти в состояние ожидания несколькими способами: поток может дожидаться, пока будет выполнена синхронизация объекта; операционная система может ждать от имени потока (например, при операции ввода-вывода); подсистема среды может дать команду потоку на приостановку. Когда состояние ожидания потока завершается, то, в зависимости от приоритета, поток либо начинает выполняться сразу же, либо возвращается в состояние готовности.
CPU Precise:график CPU Usage (Precise) содержит информацию, связанную с событиями переключения контекста. Каждая строка соответствует набору данных, связанному с одним переключателем контекста при начале выполнения потока.
% CPU Usage: использование ЦП новым потоком после его включения выражается в виде процента общего времени ЦП в отображаемом диапазоне времени.
Count: количество переключателей контекста в строке (всегда 1 для одиночных строк).
NewThreadId: идентификатор нового потока.
NewThreadStack: стек нового потока после его подключения.
ReadyingProcess: процесс, владеющий готовым потоком.
SwitchInTime(s): время переключения в новый поток.
LastSwitchOutTime (s): время последнего переключения из нового потока.
TimeSinceLast (s): SwitchInTime(s) - LastSwitchOutTime (s)

На рис. 4 показаны имена столбцов в пользовательском интерфейсе WPA.

Рисунок 4. Общий вид WPA

Generic Events:предоставленные пользователем события заполняются для анализа данных трассировки ядра.

OneShotTimer : может входить в состав всегда включенного таймера в режиме ожидания с подключением. Операционная система запускает OneShotTimer через каждые 30 секунд. Приложения могут создавать таймер, вызывая SetTimer или SetEvent.
PeriodicTimer: эти таймеры срабатывают после истечения указанного времени, а затем сбрасываются в исходное состояние.

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

Разработчики должны выполнять не менее двух тестов: базовый (без приложений) и целевой (с установленным приложением), чтобы выделить влияние приложения.

Сбор данных трассировки

Выполните команду powercfg.exe –a, чтобы убедиться, что система поддерживает режим Connected Standby.
Установите Windows Performance Analyzer из Windows ADK [4].
Запустите сбор данных трассировки, создав пакетный файл со следующей командной строкой:
- xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+CSWITCH+IDLE_STATES+POWER+TIMER+CLOCKINT+IPI+DISPATCHER+DISK_IO -stackwalk TimerSetPeriodic+TimerSetOneShot -clocktype perfcounter -buffering -buffersize 1024 -MinBuffers 128 -MaxBuffers 128

PROC_THREAD+LOADER: предоставляет информацию о прерываниях устройства и таймере.
INTERRUPT: используется для анализа событий прерывания. Предоставляет информацию, связанную с аппаратными прерываниями.
DPC: используется для анализа источников прерывания. Предоставляет информацию, связанную с журналами DPC.
CSWITCH: используется для анализа источников прерывания. Предоставляет информацию, связанную с переключателями контекста.
IPI: предоставляет информацию, связанную с прерываниями между процессорами.
TimerSetPeriodic+TimerSetOneShot: Required требуемые стеки для анализа таймера и анализа прерываний устройства.
Дайте системе войти в состояние Connected Standby (например, нажав кнопку питания)
- Подождите, пока средство xperf соберет данные трассировки в течение не менее 4 часов. При большей длительности трассировки можно лучше изучить действия программного обеспечения в режиме Connected Standby.
- Пробудите систему из состояния Connected Standby (например, нажав кнопку питания).

Остановите трассировку.

xperf -flush xperf -stop xperf -merge \kernel.etl MyTrace.etl

После завершения трассировки в текущей папке будет создан файл Mytrace.etl.

Постобработка трассировки

Выполните следующую команду для постобработки файла трассировки с информацией о пробуждении:

xperf -symbols -i mytrace1.etl -o cleanCS_diag.csv -a energydiag –verbose

Можно обработать определенную область трассировки, указав диапазон

Xperf –symbols –I mytrace1.etl –o cleanCS_diag.csv –a energygdiag –range T1 T2

Например: xperf -symbols -i -o EnergyDiag.csv -a energydiag -verbose -range 1000000 15000000000

На рис. 5 показаны файлы, созданные после постобработки.

cleanCS_diag: содержит все события и действие пробуждения системы.

MyTrace1: содержит необработанную информацию о трассировке.

Рисунок 5. Пример выходных данных трассировки

cleanCS_diag:

При постобработке собранных данных трассировки формируется журнал, содержащий количество прерываний устройств, такт таймеров и результаты для каждого ЦП. Также указывается частота устройства и действия пробуждения таймера. Постобработку также можно выполнить для данных трассировки, полученных в режиме простоя и при активной работе. Постобработка сценария помогает определить влияние работы программного обеспечения на расход электроэнергии.

Рисунок 6. Выходные данные сценария постобработки

Общее число прерываний устройства (рис. 6) является суммой количества прерываний всех модулей устройства в собранных данных трассировки. Суммарное истечение таймеров — подмножество прерываний, вызванных срабатываниями таймеров. В режиме ожидания с подключением истечение таймеров включает системные таймеры, события, а также oneshottimer и periodictimer, связанные с регулировкой.

Теперь следует понять, чем занимается система в режиме Connected Standby. Можно прокрутить отчет вниз до схемы Busy Enter/Exit Time, на которой нужно найти группу All CPUs. Значение Busy Percent позволяет точно оценить деятельность системы в режиме Connected Standby. Это дает возможность понять, насколько занята система. Чем выше показатель занятости по отношению к базовому значению, тем сильнее влияние на потребление электроэнергии. На рис. 7 показана трассировка базового значения занятости без тестовых приложений. На рис. 8 показана трассировка с несколькими запущенными приложениями и фоновой службой. Сравнение рисунков 7 и 8 показывает повышение занятости в 150 раз из-за пробуждений, вызванных приложениями, и фоновой службы.

Рисунок 7. Базовые выходные данные

Рисунок 8. Выходные данные трассировки с установленными приложениями

Анализ необработанных данных трассировки:

Также можно изучить файл трассировки непосредственно в Windows Performance Analyzer. На рис. 9 показано средство Graph Explorer в составе WPA.

Рисунок 9. Окно WPA после открытия файла трассировки

На рис. 10 показаны данные вычислений на вкладке анализа. Можно приблизить полоски действий, чтобы увидеть действия пробуждения процессов и системы. На рис. 10 показано, каким образом таймер OneShotTimer системы согласуется с действиями процессов.

Рисунок 10. Общее представление системы в режиме Connected Standby

Чтобы проверить вызовы OneShotTimer из системы, перетащите события из группы действий системы в окно анализа. Загрузить символы можно с сервера Майкрософт или из папки символов приложения, выбрав команду Load Symbols в меню Trace. На рис. 11 показан этот элемент в меню Trace.

Рисунок 11. Загрузка символов

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

Рисунок 12. График и таблица WPA

Теперь следует включить столбцы, как показано на рис. 12, чтобы проанализировать работу стека OneShotTimer.

Расположите столбцы таблицы анализа, чтобы найти действия пробуждения, запущенные системой или службами приложений. На рис. 13 показан процесс System с идентификатором потока 68, запускающий таймер OneShotTimer 36 раз в течение отображаемого отрезка времени. Пробуждение запускается системным процессом через каждые 30 секунд.

Рисунок 13. Работа стека таймера OneShotTimer в WPA

«Хорошее» и «плохое» поведение:

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

Хорошее поведение: служба приложения выполняется внутри процесса System. Т. е. служба приложения переходит в состояния сна до того, как процесс System перейдет в состояние сна. Такой подход помогает выполнить требование WHQL для режима Connected Standby в Microsoft Windows 8: в течение 16 часов ожидания с подключением может быть израсходовано не более 5 % заряда аккумулятора.

Плохое поведение: приложение работает независимо от процесса System или входит в состояние сна после того, как процесс System переходит в состояние сна. Несогласованные пробуждения могут вызвать излишний расход электроэнергии в режиме Connected Standby, из-за чего выполнить требование Microsoft WHQL будет невозможно.

На рис. 14 показано «хорошее» и «плохое» поведение в режиме ожидания с подключением.

Рисунок 14. «Хорошее» и «плохое» поведение в режиме Connected Standby

Пример 1. Доступ к хранилищу.

В программных службах, например в антивирусах и службах обновления программного обеспечения, широко распространен доступ к локальному хранилищу. Когда эти службы запущены в режиме Connected Standby, доступ к локальному хранилищу должен быть отложен до пробуждения процесса System. На рис. 15 показан сценарий доступа к хранилищу в течение примерно 65 секунд в режиме Connected Standby. Приложение пробуждается, когда процесс System (выделен оранжевым), переходит в активное состояние сна. ProcessX.exe запускает доступ к хранилищу в System32, из-за чего система не может перейти в режим Connected Standby. Можно оптимизировать приложение, исключив длительный доступ к хранилищу. Если приложению нужен доступ к хранилищу в режиме ожидания с подключением, можно объединить работу приложения с работой системы и перейти в состояние ожидания путем широковещательного уведомления об изменении состояния электропитания.

Рисунок 15. Доступ службы приложения к хранилищу в режиме Connected Standby

После этого изменения процесс доступа к хранилищу и процесс System будут объединены в режиме Connected Standby (см. рис. 16). Это пример хорошего поведения: приложение не влияет на энергопотребление системы.

Рисунок 16. Оптимизированный доступ к хранилищу в режиме Connected Standby

Пример 2. Пробуждение потоков приложения.

Оптимизация пробуждения приложения, вызванного ОС, — непростая задача. Необходимо понимать события ЦП Precise и Generic, чтобы узнать, происходит ли OneShotTimer при пробуждении процесса System. На рис. 16 показано пробуждение потоком приложения, когда процесс System находится в состоянии сна. Это образец неправильного написания служб процессов, которые без необходимости поддерживают систему в пробужденном состоянии. ProcessX.exe (ID: 2440) создает несколько потоков. В таблице на рис. 16 видны два потока, не согласованных с процессом System. Используя общую таблицу событий, можно сопоставить идентификатор потока с setTimer и прерываниями часов. Как показано на рис. 16, существуют задачи потока Timer Set, которые следует рассмотреть (идентификаторы потоков 3432 и 1824). Теперь следует сопоставить идентификатор потока, полученный на предыдущем шаге (Thread ID 3432 и Thread ID 1824) с таблицей CPU Usage (Precise), чтобы найти деятельность, связанную с этими потоками. Деятельность может быть связана с Timer Set, с расписанием потоков или с действиями ввода-вывода. Для наглядного отображения можно построить несколько графиков в одном представлении.

Рисунок 17. Потоки приложений поддерживают систему активной в состоянии сна

Функцию SetTimer можно использовать для изменения таймера потока в приложении.

UINT_PTR WINAPI SetTimer(
  _In_opt_  HWND hWnd,
  _In_      UINT_PTR nIDEvent,
  _In_      UINT uElapse,
  _In_opt_  TIMERPROC lpTimerFunc
);

Окно приложения (HWND) используется для обработки уведомлений посредством процедуры window, которую следует вызвать через количество микросекунд, заданное значением uElapse, даже после перехода процесса System в режим Connected Standby.

Если в приложении есть окно (HWND) и нужно обрабатывать эти уведомления посредством процедуры window, чтобы это исправить, вызовите RegisterSuspendResumeNotification для регистрации этих сообщений (или UnregisterSuspendResumeNotification для отмены регистрации). Можно использовать DEVICE_NOTIFY_WINDOW_HANDLE в параметре Flags и передавать значение окна HWND в параметре Recipient. Получено сообщение WM_POWERBROADCAST.

Если приложение не имеет обработчика HWND или если нужен прямой обратный вызов, вызовите PowerRegisterSuspendResumeNotification для регистрации на эти сообщения (или PowerUnregisterSuspendResumeNotification для отмены регистрации). Можно использовать DEVICE_NOTIFY_WINDOW_HANDLE в параметре Flags и передавать значение типа PDEVICE_NOTIFY_SUBSCRIBE_PARAMETERS в параметре Recipient.

Заключение

Реализация режима ожидания с подключением в приложениях крайне важна для продления времени работы от аккумулятора. Системы, поддерживающие режим Connected Standby, должны отвечать требованиям сертификации оборудования Windows Hardware Certification (WHCK) в отношении потребления электроэнергии. Согласно этим требованиям, все системы в режиме Connected Standby должны израсходовать не более 5 % заряда аккумулятора в течение 16-часового периода бездействия в фабричной конфигурации по умолчанию. Сертификационный тест находится на сайте Microsoft WHCK.

Об авторе

Мануж Сабарвал (Manuj Sabharwal) работает инженером по программному обеспечению в отделе Software Solutions Group корпорации Intel. Мануж изучает возможные способы повышения эффективности расхода электроэнергии программами в активном состоянии и в состоянии простоя. Он обладает высокой научно-технической квалификацией в области эффективности расхода электроэнергии; им разработан ряд учебных и технических справочников, применяющихся в данной отрасли. Также он работает над поддержкой клиентских платформ путем оптимизации программного обеспечения.