ЦП хоста не масштабирует частоту, когда это требуется гостю KVM

8

Замечание: у
меня есть сервер 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)

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

Гюйгенс
источник
1
Этот микросервер поддерживает только Windows и RHEL, см. Краткие спецификации.
запустить cpufreq-infoна хост-ОС, он, вероятно, будет жаловаться, что нет доступных драйверов.
Крис С
Официально поддерживает Windows и RHEL. Я не имею в виду, что другие ОС не будут работать поверх него. Обратите внимание, что масштабирование ЦП прекрасно работает в Ubuntu и FreeBSD, когда они установлены на «голое железо» (не через виртуализацию). Кроме того, при установке на голое железо обе ОС работают отлично, отсутствует драйвер или странное поведение. Наконец, cpufreq-infoне жалуется и выводит правильную информацию, поэтому процессор полностью поддерживается (конечно, в пути!). Используемый драйвер - PowerNow-K8, что также логично.
Гюйгенс
@ChrisS Я добавил информацию cpufreq-info к исходному вопросу.
Гюйгенс
Если вам действительно не нужно масштабирование частоты, вы всегда можете отключить его.
Майкл Хэмптон

Ответы:

10

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

Тюнинг 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 в качестве источника.

Гюйгенс
источник
для этого есть реальное применение или это разовый трюк?
13
@ белый, что вы подразумеваете под одноразовым трюком? Вывод заключается в том, что DVFS (динамическое масштабирование напряжения и частоты) фактически работает с KVM и хостом Linux. Загрузка ЦП процесса в 80-140%, вероятно, была распределена по обоим ядрам равномерно, поэтому ни одно ядро ​​не достигло порогового значения по умолчанию 95%, что привело бы к масштабированию частоты. Ничего не меняя, если я действительно создаю однопотоковый процесс, который использует 100% одного ядра в виртуальной машине, то запускается масштабирование частоты, поэтому я просто не видел его. Что касается реального применения DVFS, речь идет об экономии энергии и снижении температуры.
Гюйгенс,
@ewwhite Вы имеете в виду "есть приложение, которое настраивает это значение для меня?" Я думаю, что ответ - нет. В противном случае кто-то уже установил бы разумный дефолт. 95 определенно не имеет смысла здесь.
Майкл Хэмптон
Нет, есть ли приложение (причина), чтобы хотеть использовать это в виртуализированной установке?
ewwhite
Причина: я не хочу, чтобы процессор работал на полной скорости по нескольким причинам: энергопотребление выше, температура выше, износ быстрее, вентилятор вращается быстрее (больше энергии и быстрее изнашивается), требуется больше батареи ИБП.
Гюйгенс
4

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

Nils
источник
Интересно, вы случайно не знаете, как это сделать?
Гюйгенс
@Huygens Обычно это делается с помощью какого-либо cpufrequency-daemon. Для этого демона есть файл конфигурации, где вы можете изменить его поведение и значения вверх / вниз. Не уверен, где именно это находится в Ubuntu.
Нильс
Вы решили это, по умолчанию (по крайней мере в Ubuntu) порог составляет 95%, хотя я не уверен, что он на процессор. При снижении до 50% у меня ожидаемое поведение! На Ubuntu вы бы сделали это следующим образом: sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"Источник: ivanlam.info/blog/2012/04/26/…
Huygens
1
@Huygens У меня была эта проблема на CentOS - там файл конфигурации для cpuspeedнаходится в / etc / sysconfig / cpuspeed, чтобы сделать такое изменение постоянным. В моем случае у меня была VBox-VM с одним процессором (физически двухъядерный). Мне пришлось понизить уровень до 45%, чтобы получить эффект высокого уровня в ВМ.
Нильс
2

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

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

dyasny
источник
Как ни странно, когда я делаю top на хосте, я вижу, что общее потребление ресурсов процессора составляет около 80-130% (между прочим, все они потребляются процессами kvm и ksm), но не масштабирование частоты. Когда я запускаю другие процессы, которые используют ЦП, быстро запускается регулятор по требованию! Единственное отличие, которое я предполагаю, состоит в том, что в процессе kvm используется некая технология виртуализации (в моем случае AMD svm), которая может привести к тому, что управляющий узел не будет реагировать. И гость не может запросить базовый hw в масштабе, я думаю, хотя на голом металле это сработало.
Гюйгенс
Не могли бы вы сослаться на статью, в которой подробно объясняется, почему масштабирование частоты не рекомендуется при работе виртуальных машин? Мне любопытно понять почему. Red Hat, кажется, поддерживает это, см. Главу 6.2.4 (в более раннем выпуске, чем RHEL 5.3 была проблема) access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/…
Huygens
У меня нет удобных статей, но подумайте, для чего нужна виртуализация и как она работает. Вы планируете использовать недостаточно загруженную машину, загружая ее виртуальными машинами. Виртуальные машины должны быть стабильными и предсказуемыми. Считаете ли вы, что регулировка частоты процессора под виртуальными машинами поможет с этим? И если говорить о лучших практиках, то, по моему опыту, Ubuntu в качестве хоста virt - не очень хорошая идея
2013 года
Вы можете переносить виртуальные машины между разными хостами, иногда различаясь по частоте. В этом случае должна быть стабильной функция, предоставляемая центральным процессором с хоста, так что если SSE4 открыт и ваше приложение использует его, после перехода на процессор, который его не поддерживает, ваша виртуальная машина не врезаться. Поэтому масштабирование частоты, которое является важным фактором снижения энергопотребления, не должно быть проблемой. Я гуглил это и не нашел никакой статьи, упоминающей это.
Гюйгенс,
1
Что касается дистрибутива, я упомянул Ubuntu как проблемный, потому что это так. И на SF, и на других сайтах я постоянно вижу людей, сообщающих о проблемах, связанных с KVM, которые мне никогда не удается воспроизвести на Fedora или RHEL. Пожалуйста, не стесняйтесь не соглашаться, я не продолжаю в огненную войну здесь.
Десятый