观察：
我有一台带有AMD双核CPU（Turion II Neo N40L）的HP服务器，它可以将频率从800扩展到1500 MHz。频率缩放可在FreeBSD 9和Linux内核3.5的Ubuntu 12.04下使用。但是，当我将FreeBSD 9放在Ubuntu之上的KVM环境中时，频率缩放不起作用。来宾（因此，FreeBSD）不会检测最小和最大频率，因此在CPU占用率较高时不会扩展任何内容。在主机（因此是Ubuntu）上，KVM进程使用了​​80％到140％的CPU资源，但没有发生频率缩放，频率保持在800 MHz，尽管当我在同一Ubuntu机器上运行任何其他进程时，按需调速器很快将频率扩展到1500 MHz！

关注和问题：
我不了解CPU可能如何虚拟化，以及是否由来宾执行适当的扩展。它是否需要向来宾显示一些CPU功能才能起作用？

Apendix：
在下面的Red Hat发布说明倾向于认为，频率缩放出来工作，即使在虚拟化环境中（参见第6.2.2和6.2.3），认为注未能解决其虚拟化技术与（KVM，Xen的这项工作等？）

有关信息，cpufreq-infoUbuntu上的输出为：

$ 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)

我希望此功能起作用的原因是：节省能源，运行安静（较少发热量）以及好奇心，以便更好地了解为什么不起作用以及如何使其起作用。

我找到了解决方案，这要归功于Nils给出的技巧和一篇不错的文章。

调整按需 CPU DVFS调速器

按需调速器具有一组参数，可控制何时启动动态频率缩放（或用于动态电压和频率缩放的DVFS）。这些参数位于sysfs树下：/sys/devices/system/cpu/cpufreq/ondemand/

这个参数之一就是up_threshold一个阈值（单位是CPU的百分比，我还没有找到，尽管这是每个内核还是合并的内核），高于该阈值时，按需调节器将启动并开始动态更改频率。

使用sudo将其更改为50％很简单：
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上。

我发现我的来宾VM尽管在主机上消耗了大量CPU（80-140％），但正在分配两个内核的负载，所以没有一个内核超过95％，因此，令我恼火的CPU是保持在800 MHz 现在有了上述补丁，CPU可以更快地动态更改每个内核的频率，这更适合我的需求，50％似乎是我的客人使用的更好阈值，您的里程可能会有所不同。

（可选）验证您是否正在使用HPET

某些不正确实现计时器的适用组件可能会受到DVFS的影响。尽管主机可以使用一些复杂的算法来尝试将其最小化，但这在主机和/或来宾环境上可能是一个问题。但是，现代CPU具有与当前CPU /核心频率无关的更新的TSC（时间戳计数器），它们是：常数（constant_tsc），不变（invariant_tsc）或不间断（nonstop_tsc），请参阅Chromium上有关TSC重新同步的文章有关每个的更多信息。因此，如果您的CPU配备了该TSC之一，则无需强制使用HPET。要验证您的主机CPU是否支持它们，请使用类似的命令（将grep参数更改为相应的CPU功能，此处我们测试常数TSC）：

$ grep constant_tsc /proc/cpuinfo

如果您没有此现代TSC之一，则应该：

1. 有源HPET，下面将对此进行描述；
2. 如果VM中有任何应用程序依赖精确的时序（这是Red Hat推荐的时序），则不要使用CPU DVFS 。

一个安全的解决方案是启用HPET计时器（有关更多详细信息，请参见下文），它们的查询速度比TSC计时器（TSC在CPU中，而HPET在主板中）要慢，并且可能不精确（HPET> 10MHz； TSC）通常是最大CPU时钟），但它们的可靠性要高得多，尤其是在DVFS配置中，每个内核可能具有不同的频率。Linux足够聪明，可以使用最好的计时器，它将首先依赖TSC，但是如果发现它不太可靠，它将使用HPET。这在主机（裸机）系统上可以很好地工作，但是由于并非虚拟机管理程序可以正确导出所有信息，因此对于来宾VM而言，检测行为不佳的TSC更具挑战性。诀窍是迫使访客在访客中使用HPET，尽管您需要虚拟机监控程序才能使访客使用此时钟源！

您可以在下面找到如何在Linux和FreeBSD上配置和/或启用HPET。

Linux HPET配置

HPET或高精度事件计时器是自2005年以来在大多数商用PC中都可以找到的硬件计时器。现代操作系统可以有效使用此计时器（Linux内核从2.6开始支持它，从最新的9.x起在FreeBSD上一直提供稳定的支持。但在6.3中引入），始终为CPU电源管理提供一致的时序。它还允许构建更容易的无滴答调度程序实现。

基本上，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：如何在FreeBSD上强制使用HPET。

虚拟机监控程序HPET导出

主机支持后，KVM似乎会自动导出HPET。但是，对于Linux guest虚拟机，他们将更喜欢另一个自动导出的时钟kvm-clock（主机TSC的半虚拟化版本）。有人报告首选时钟的问题，您的里程可能会有所不同。如果要在来宾中强制使用HPET，请参阅上一节。

默认情况下，VirtualBox不会将HPET时钟导出到来宾，并且GUI中没有选项。您需要使用命令行并确保VM已关闭电源。命令是：

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

如果在上述更改之后，来宾继续选择除HPET以外的其他来源，请参考上一节如何强制内核将HPET时钟用作来源。

触发升级的不是访客，主机必须执行此操作。因此，您必须降低主机上的相应触发级别。

在主机上，kvm cpu看起来像一个进程。缩放机制不监视进程，而仅监视整体cpu消耗。

通常最好的做法是在运行VM时禁用cpu缩放/限制/等