Замечание: у
меня есть сервер HP с двухъядерным процессором AMD (Turion II Neo N40L), который может масштабировать частоты от 800 до 1500 МГц. Масштабирование частоты работает под FreeBSD 9 и под Ubuntu 12.04 с ядром Linux 3.5. Однако когда я помещаю FreeBSD 9 в среду KVM поверх Ubuntu, масштабирование частоты не работает. Гость (то есть FreeBSD) не определяет минимальную и максимальную частоты и, следовательно, ничего не масштабирует, когда загрузка процессора возрастает. На хосте (то есть Ubuntu) процесс KVM использует от 80 до 140% ресурсов ЦП, но масштабирование частоты не происходит, частота остается на уровне 800 МГц, хотя, когда я запускаю любой другой процесс на том же компьютере с Ubuntu, регулятор по требованию быстро масштабирует частоту до 1500 МГц!

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

Приложение.
В следующей заметке о выпуске Red Hat предполагается, что масштабирование частоты будет работать даже в виртуализированной среде (см. Главы 6.2.2 и 6.2.3), хотя в этой заметке не указывается, с какой технологией виртуализации эта работа (kvm, xen) , так далее.?)

Для информации, cpufreq-infoвывод на Ubuntu:

$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.79%, 1.30 GHz:1.07%, 1000 MHz:0.71%, 800 MHz:83.43%  (277433)
analyzing CPU 1:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.56%, 1.30 GHz:1.06%, 1000 MHz:0.79%, 800 MHz:83.59%  (384089)

Я хочу, чтобы эта функция работала: экономить энергию, работать тише (менее жарко), а также просто любопытствовать, чтобы лучше понять, почему это не работает и как заставить его работать.

Я нашел решение благодаря подсказке Нильса и хорошей статье .

Тюнинг OnDemand губернатора DVFS CPU

Регулятор по требованию имеет набор параметров для управления, когда он запускает динамическое масштабирование частоты (или DVFS для динамического напряжения и масштабирования частоты). Эти параметры находятся под деревом sysfs:/sys/devices/system/cpu/cpufreq/ondemand/

Один из этих параметров, up_thresholdкоторый, как следует из названия, представляет собой пороговое значение (единица измерения -% ЦП, хотя я не выяснил, относится ли это к ядру или объединенным ядрам), выше которого срабатывает регулятор по требованию и начинают динамически изменять частоту.

Изменить его на 50% (например) с помощью sudo просто:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"

Если вы являетесь пользователем root, возможна еще более простая команда:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Примечание: эти изменения будут потеряны после следующей перезагрузки хоста. Вы должны добавить их в файл конфигурации, который читается во время загрузки, как /etc/init.d/rc.localв Ubuntu.

Я обнаружил, что моя гостевая виртуальная машина, хотя и потребляла много ресурсов ЦП (80-140%) на хосте, распределяла нагрузку на оба ядра, поэтому ни одно ядро ​​не превышало 95%, поэтому ЦП, к моему раздражению, был оставаясь на 800 МГц. Теперь с помощью вышеупомянутого патча процессор динамически меняет частоту на ядро ​​намного быстрее, что лучше соответствует моим потребностям, 50% кажется лучшим порогом для моего гостевого использования, ваш пробег может варьироваться.

При необходимости проверьте, используете ли вы HPET

Возможно, что некоторые применимые, которые неправильно используют таймеры, могут быть затронуты DVFS. Это может быть проблемой в хосте и / или гостевой среде, хотя хост может иметь некоторый запутанный алгоритм, чтобы попытаться минимизировать это. Однако современные ЦП имеют более новые TSC (счетчик меток времени), которые не зависят от текущей частоты ЦП / ядра, а именно: постоянный (constant_tsc), инвариантный (invariant_tsc) или безостановочный (nonstop_tsc), см. Эту статью Chromium о ресинхронизации TSC для получения дополнительной информации о каждом. Так что, если ваш процессор оснащен одним из этих TSC, вам не нужно форсировать HPET. Чтобы проверить, поддерживает ли их ваш центральный процессор, используйте аналогичную команду (измените параметр grep на соответствующую функцию CPU, здесь мы проверяем постоянную TSC):

$ grep constant_tsc /proc/cpuinfo

Если у вас нет одного из этих современных TSC, вам следует:

1. Активный HPET, это описано здесь после;
2. Не используйте CPU DVFS, если у вас есть какие-либо приложения на ВМ, которые полагаются на точную синхронизацию, что рекомендовано Red Hat .

Безопасное решение состоит в том, чтобы включить таймеры HPET (подробнее см. Ниже), они медленнее запрашивают, чем TSC (TSC в процессоре, а HPET в материнской плате) и, возможно, не имеют точных (HPET> 10 МГц; TSC часто это максимальные тактовые частоты процессора), но они гораздо надежнее, особенно в конфигурации DVFS, где каждое ядро ​​может иметь разную частоту. Linux достаточно умен, чтобы использовать лучший из доступных таймеров, он будет полагаться сначала на TSC, но если он окажется слишком ненадежным, он будет использовать HPET. Это хорошо работает на хост-системах (голые металлы), но из-за того, что гипервизор не экспортирует должным образом всю информацию, гостевой виртуальной машине становится сложнее обнаружить плохо функционирующий TSC. Хитрость заключается в том, чтобы заставить HPET использовать гостевую систему, хотя вам потребуется гипервизор, чтобы сделать этот источник синхронизации доступным для гостей!

Ниже вы можете найти, как настроить и / или включить HPET в Linux и FreeBSD.

Конфигурация Linux HPET

HPET, или высокоточный таймер событий, является аппаратным таймером, который вы можете найти в большинстве обычных ПК с 2005 года. Этот таймер может эффективно использоваться в современных ОС (ядро Linux поддерживает его с 2.6, стабильная поддержка FreeBSD начиная с последней версии 9.x). но был введен в 6.3 ) для обеспечения согласованной синхронизации неизменно для управления питанием процессора. Это позволяет также создавать более простые реализации без тиканья .

По сути, HPET - это барьер безопасности, который, даже если на хосте активен DVFS, будет меньше влиять на события синхронизации хоста и гостя.

В IBM есть хорошая статья о включении HPET , в которой объясняется, как проверить, какой аппаратный таймер используется вашим ядром, а какой доступен. Я приведу здесь краткое резюме:

Проверка доступных аппаратных таймеров:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Проверка текущего активного таймера:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Более простой способ принудительного использования HPET, если он у вас есть, - это изменить загрузчик, чтобы попросить его включить (начиная с ядра 2.6.16). Эта конфигурация зависит от дистрибутива, поэтому, пожалуйста, обратитесь к собственной документации по дистрибутиву, чтобы установить ее правильно Вы должны включить hpet=enableили clocksource=hpetв строке загрузки ядра (это опять-таки зависит от версии ядра или дистрибутива, я не нашел никакой связной информации).
Это убедитесь, что гость использует таймер HPET.

Примечание: в моем ядре 3.5 Linux, похоже, автоматически запускает таймер hpet.

Гостевая конфигурация FreeBSD HPET

Во FreeBSD можно проверить, какие таймеры доступны, запустив:
sysctl kern.timecounter.choice

Текущий выбранный таймер можно проверить с помощью:
sysctl kern.timecounter.hardware

FreeBSD 9.1, похоже, автоматически предпочитает HPET другим провайдерам таймеров.

Todo: как заставить HPET работать на FreeBSD.

Гипервизор HPET экспорт

Кажется, KVM автоматически экспортирует HPET, когда хост поддерживает его. Однако для гостя Linux они предпочтут другие автоматически экспортируемые часы, которые представляют собой kvm-clock (паравиртуализированная версия хоста TSC). Некоторые люди сообщают о проблемах с предпочтительными часами, ваш пробег может отличаться. Если вы хотите принудительно использовать HPET в гостевой системе, обратитесь к разделу выше.

VirtualBox по умолчанию не экспортирует часы HPET в гостевую систему, и в графическом интерфейсе нет возможности сделать это. Вам нужно использовать командную строку и убедиться, что виртуальная машина выключена. команда:

./VBoxManage modifyvm "VM NAME" --hpet on

Если гость продолжает выбирать источник, отличный от HPET, после вышеуказанного изменения, обратитесь к приведенному выше разделу, чтобы заставить ядро ​​использовать часы HPET в качестве источника.

Это не гость, который запускает высококлассные - хост должен сделать это. Таким образом, вы должны понизить соответствующий уровень триггера на хосте.

на хосте процессор kvm выглядит как процесс. Механизм масштабирования не отслеживает процессы, а только общее потребление ресурсов процессора.

и, как правило, рекомендуется отключать масштабирование / регулирование процессора / и т. д. при работе виртуальных машин.