Профилирование энергопотребления виртуальных машин (1187417), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

В [29] приводится характеристика всех известных методов power profiling. Перечислено большое количество софтварных и хардварных методов. Но для виртуализации там ничего нового нет, кроме того что уже перечислено выше.

1. Устройство техник профилирования энергопотребления

Известно, что наибольший вклад в энергопотребление платформы вносит процессор. В связи с этим компании Intel, Microsoft и некоторые другие представили свои средства измерения мощности. Каждое из них собирает различные данные разными способами. Для начала стоит немного сказать об основных аппаратных средствах измерения энергопотребления, предоставляемых платформой. В их число входят MSR (Model-Specific Registers) и HPC (Hardware Performance Counters). Со встроенных в оборудование датчиков и счетчиков HPC собираются данные для определения того, какие события сильно коррелируют с потреблением энергии. Далее, на основании того на сколько сильна эта взаимосвязь между данными HPC и энергопотреблением, строится модель прогнозирования будущих энергозатрат. MSR-ы используются для мониторинга производительности и контроля датчиков оборудования. Доступ к этим регистрам можно получить с помощью двух инструкций – rdmsr и wrmsr. Доступ к MSR из пространства пользователя в Linux осуществляется через модуль ядра, который называется msr. Когда этот модуль загружен, открывается доступ к интерфейсу /dev/cpu/x/msr. Этот файловый интерфейс предназначен для чтения и записи в любой MSR на данном CPU. MSR-ами программируется один из основных механизмов определения энергопотрбления - это RAPL интерфейс (Running Average Power Limit). RAPL MSR-ы предоставляют доступ к внутрипроцессорным датчикам мощности (поэтому поддерживаются процессоры Sandy Bridge, Ivy Bridge и более новые). Например, RAPL_PKG_ENERGY_STATUS MSR используется как счетчик, определяющий количество ватт, потребленное системой с момента запуска. А регистр RAPL_POWER_UNIT содержит данные, переводящие значение счетчика в реальные цифры потребляемой мощности и энергии. Помимо MSR и HPC, при замерах важно следить за частотой переключения уровней энергопотребления при помощи технологий Intel C-states и P-states, на основе которых определяется схема энергопотребления процессора с помощью стандарта Advanced Configuration and Power Interface (ACPI).

Самым простым инструментом измерения энергопотребления можно назвать Joulemeter от Microsoft. В основе его расчетов лежат данные о потреблении специфической программой или виртуальной машиной аппаратных ресурсов системы – центрального процессора, жестких дисков, памяти, дисплея и др. Эти сведения конвертируются в показатели фактического энергопотребления, что достигается за счет чтения значений некоторых MSR-ов, как например MSR_PKG_ENERGY_STATUS, MSR_FUNC_POWER, и некоторых HPC, например - CPU_CLK_UNHALTED.CORE и CPU_CLK_UNHALTED.REF (процент времени, в течение которого процессор активен за определенный интервал времени). Для оценки энергопотребления памяти используется last level cache (LLC) miss counter. Также для прогнозирования включен механизм использования P- и C-states, которые учитываются следующим образом: для данного состояния считается утилизация процессора через HPC, и тогда общее потребление за определенный промежуток времени - это произведение этой утилизации на некоторый коэффициент, для вычисления которого используется механизм обучения на основе линейной регрессии.

Joulemeter весьма неплохое средство, но оно все же уступает место следующему инструменту оценки энергопотребления - PowerTop в виду его большей информативности и открытому исходному коду. PowerTop предоставляет информацию по уровню потребления энергии каждым процессом в режиме реального времени. Это достигнуто с помощью деления общего потребления энергии в системе (берется из ACPI) по времени исполнения каждого процесса на процессоре в микросекундах за секунду. Механизм измерения построен на системных профилировщиках. PowerTop собирает информацию из различных источников ядра (таких как /proc, /sys, ACPI) и отображает результат работы системы в одном окне так, что можно увидеть насколько хорошо работает система, и какие компоненты наиболее проблемные. Одним из преимуществ PowerTop является то, что он может находить программные компоненты, которые вынуждают систему потреблять больше энергии, чем это необходимо, в то время как она находится в режиме ожидания. Также преимуществом является достаточно большая информативность: wakeups (пробуждение в секунду), информация о состоянии С- и P- states, потребляемая мощность, оценку, сколько часов работы от батареи осталось.

Самое точное и простое по устройству средство профилирования энергопотребления - это Intel PowerGadget. Для оценки используется работа с RAPL MSR-ами. Среди дополнительных функций - измерения потребляемой мощности многопроцессорными системами, а также вызываемые извне API для извлечения данных о потребляемой мощности в коде.

Далее кратко описаны еще несколько средств измерения энергопотребления, которые менее практичны из-за недоступной программной реализации. VMeter может прогнозировать общее потребление энергии, основан на Oprofile, следит за некоторыми HPC: CPU_CLK_UNHALTED, DRAM_ACCESSES, INSTRUCTION_CACHE_FETCHES, DATA_CACHE_FETCHES, которые имеют большую корреляцию с потреблением энергии, и проецирует их на реальное энергопотребление. К сожалению, вначале должен подключаться PDU (Power distribution units) и снимаются общие данные. CloudMonitor - может прогнозировать общее энергопотребление всей машины после того, как модель будет обучена на конкретной конфигурации железа. Модель потребления построена на основании использования ресурсов: CPU, память, диск, сеть.

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

1. уменьшение количества ресурсов приложения при использовании батареи;

2. использование аппаратных средств сбережения энергии: при помощи C3-state и координирования взаимодействия между ядрами одного процессора;

3. корректное исполнение переходов между S1 - S4 состояниями;

4. поддержка работы процессора на высоких P-states, когда не требуется слишком большая производительность;

5. поддержка работы процессора на более глубоких С-states в отсутствие частой активности процессора.

Также необходимо перечислить некоторые платформозависимые возможности оптимизации энергопотребления:

1) выключение неиспользуемых устройств.

2) При разработке network-intensive приложений, это касается переключения на LAN с WLAN при подключении обоих, пересылка данных по WLAN большими частями, чтобы Wi-Fi карточка была в более низком режиме потребления.

3) Избегать частого обращения к диску.

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

1. Инструменты Power-management, доступные разработчику

Чтобы исследовать этот вопрос в полной мере, согласно [30], в первую очередь стоит обратиться к спецификации стандарта ACPI [6], регламентирующего интерфейс регулирования энергопотребления операционной системой. Он объединяет ряд методик по снижению энергозатрат, опирающихся на достаточно очевидную идею: для устройства должен быть реализован набор состояний с пониженными запросами по энергии, но с урезанной в той или иной степени функциональностью. В случае, когда полная функциональность не востребована, есть резон в эти состояния переходить.

Важно осознавать, что переключение между состояниями не происходит мгновенно [7][16]. Переходы в более глубокие состояния сна происходят ступенчато и со временем, чтобы в случае необходимости максимально быстро вернуться в рабочее состояние. Принимая во внимание эти факты, можно уловить основную идею большинства методов энергосбережения: группировать обращения к устройству для увеличения длительности непрерывных интервалов простоя, чтобы устройство могло больше времени провести в наиболее глубоком состоянии сна.

Для CPU есть два основных набора состояний, позволяющих регулировать энергопотребление:

P-states. Это состояния активной работы. P-state – пара частоты процессора и напряжения. Для каждого ядра P-state может быть выбран индивидуально, но при этом нужно понимать, что в рамках одного package могут существовать аппаратные ограничения на одновременные изменения состояний разными ядрами. Так, например, вольтаж в процессоре Pentium 4 не мог опуститься ниже, чем самый высокий запрошенный [8]. Для управления этими состояниями используются Model Specific Reristers IA32_PERF_CTL\IA32_PERF_STATUS.

C-States. В эти состояния процессор входит при исполнении ассемблерных инструкций HLT/MWAIT (команды остановки активного исполнения). Каждому из них соответствуют различные уровни сна (оставляем ли напряжение на кэшах, держим ли напряжение на буферах), из более низких дольше просыпаться (от 10 до 100 микросекунд [16]). По этой причине ядро спускается в “состояние глубокого сна” не сразу, а постепенно. Так что излишне частые пробуждения процессора в связи с активностью пользовательского приложения указывают на неэффективность этого приложения с точки зрения энергопотребления.

Для любознательного системного разработчика может оказаться интересной разница между двумя упомянутыми методами остановки работы CPU. HLT останавливает процессор до первого пришедшего прерывания. Связка MONITOR/MWAIT позволяет реализовать более интеллектуальный сценарий: при помощи MONITOR устанавливается некий адрес памяти, за которым будет происходить наблюдение, а после вызова MWAIT процессор уснет, пока не будет произведена запись в указанную область памяти. Это позволяет избавиться от busy-waiting в случае реализации примитивов синхронизации на уровне ядра ОС.

Помимо того, процессоры Intel содержат в себе набор эвристических алгоритмов управления энергопотреблением, и у разработчика есть возможность повлиять на их работу записью в MSR IA32_ENERGY_PERF_BIAS. Предполагается существование 16 уровней производительности (0 – максимальная производительность, 15 – максимальное энергопотребление/минимальная производительность).

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

1. Инструмены энергопрофилирования, доступные разработчику

Теперь рассмотрим аппаратные инструменты энергопрофилирования. С аппаратными средствами измерения абсолютных показателей потребления энергии у процессоров Intel долгое время была проблема: их не было. Вернее говоря, такие средства были реализованы как отдельные устройства, подключаемые к материнской плате (или, например, как Watts Up, через USB [19]), что достаточно неудобно, а порой почти нереализуемо (например, если нет физического доступа к машине).

Но уже процессоры Pentium содержали в себе модуль измерения производительности (Performance Monitoring Unit), который давал возможность собирать статистику по количеству аппаратных событий, происходящих в процессоре (например, количество исполненных инструкций, промахов кешей и т.д.). На базе этой статистики долгое время и производились оценки энергопотребления. Происходило это следующим образом: строилось некоторое предположение о корреляции между измеряемыми метриками и энергопотреблением системы (энергетическая модель), и далее, когда профайлер с заложенной моделью попадал на целевую машину, запускался процесс калибровки, связывающий оригинальные метрики и реальное энергопотребление. Далее по полученным коэффециентам можно оценивать энергопотребление.

Нетрудно догадаться, что такой подход не может гарантировать безошибочный результат, и поэтому в архитектуру Sandy Bridge был заложен RAPL интерфейс (Running Average Power Limit). После этого через набор msr’ов стало возможно получить информацию о количестве энергии, потребленной системой с момента запуска. Естественно, после этого обсуждать профилировщики, работающие на базе счетчиков производительности, кажется бессмысленным, но это не совсем так, ведь встретить машину, не оснащенную процессором на архитектуре Sandy Bridge и старше, все еще очень несложно, и RAPL позволяет оценивать только энергопотребление CPU, чего в некоторых случаях может быть недостаточно.

1. Утилиты измерения энергопотребления

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

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

PowerTop[10] (Linux) – эта утилита предоставляет информацию по энергопотреблению процессов системы в режиме реального времени. В своих выводах опирается на энергетическую модель, учитывающую потребление CPU, Network-devices, GPU и HDD [11]. Вносит overhead порядка 3%, что соответствует среднему значению для профилировщиков производительности. Среди безусловных плюсов стоит отметить то, что эта утилита сможет работать на большинстве существующих CPU от Intel (начиная с Core 2 Duo). Помимо того, инструмент предоставляет простой доступ к ряду параметров управления энергопотреблением системы, а также показывает, какие компоненты наиболее проблемные и приводит конкретные предложения по настройке с целью уменьшения потребления энергии. Примерами таких рекомендаций могут служить - включение энергосбережения Wi-Fi, перевод AC97 в режим энергосбережения, выключение звука, включение режима энергосбережения PCI Express и SATA-устройств, выключение опроса CDROM с помощью HAL, включение экономии энергии в настройках звукового чипа HDA и т.д. Также PowerTop может посоветовать изменения некоторых конфигураций ядра, например - dirty ratio, dirty background ratio, sched_mc_power_savings и т.п. Но стоит понимать, что утилита может выдавать статистику только по процессам, что значит, что профилирование конкретного приложения при помощи PowerTop является нетривиальной задачей, так как нет никакой привязки полученной статистики к исходному коду. В качестве источники данных PowerTop полагается на данные от PMU, которые по некоторым коэффициентам ставит в соответствие потребляемой электроэнергии.

Joulemeter[14] (Windows) – профилировщик, использующий, как и PowerTop, метрики производительности для оценки затраченной энергии [15]. Учитывает затраты CPU, HDD, GPU, сетевых устройств и экрана. Так же, как и PowerTop, не дает возможности связывать статистику с исходным кодом приложения, хотя и является удобным инструментом для анализа энергопотребления системы в целом. Так же как и PowerTop, Joulemeter полагается на статистику от PMU

Далее рассмотрим утилиты, которые помимо метрик производительности используют RAPL-интерфейс (прямые измерения энергопотребления CPU).

Intel Power Gadget [12] (Linux, Windows, OS X) - профилировщик, предоставляющий статистику по энергопотреблению выбранного пользователем приложения на машинах с CPU на базе Sandy Bridge и новее. Предоставляет также Power Gadget API, позволяющий пользовательским приложениям получать метрики энергопотребления. Так же, как и PowerTop, не может связывать статистику с исходным кодом.

Характеристики

Список файлов ВКР