小编Edd*_*ett的帖子

我正在运行一些基准测试。我的基准运行程序监视实验之间的 dmesg 缓冲区，寻找可能影响性能的任何内容。今天它抛出了这个：

[2015-08-17 10:20:14 WARNING] dmesg 好像变了！差异如下：
--- 2015-08-17 09:55:00
+++ 2015-08-17 10:20:14
@@ -825,3 +825,4 @@
 [3.802206][drm]启用RC6状态：RC6开启，RC6p关闭，RC6pp关闭
 [7.900533]r8169 0000:06:00.0 eth0：链接
 [7.900541]IPv6：ADDRCONF（NETDEV_CHANGE）：eth0：链接准备好
+[236832.221937] perf 中断时间太长 (2504 > 2500)，将 kernel.perf_event_max_sample_rate 降低到 50000

经过一番搜索，我现在知道这与 linux 内核中名为“perf”的分析子系统有关。我认为我们不需要这个，所以我想完全禁用它。

再次搜索，我发现 sysctlperf_cpu_time_max_percent可以提供帮助。这里有人建议通过将其设置为 0 来禁用。在这里阅读更多内容：

perf_cpu_time_max_percent：

向内核提示应该允许使用多少 CPU 时间来处理性能采样事件。如果 perf 子系统被告知其样本超过此限制，它将降低其采样频率以尝试减少其 CPU 使用率。

一些性能采样发生在 NMI 中。如果这些样本意外地花费了太长时间来执行，则 NMI 可能会彼此堆叠在一起，以至于不允许执行任何其他操作。

0：禁用该机制。无论 CPU 时间有多长，都不要监视或更正 perf 的采样率。

1-100：尝试将 perf 的采样率限制到 CPU 的这个百分比。注意：内核计算每个样本事件的“预期”长度。这里的 100 表示预期长度的 100%。即使将其设置为 100，如果超过此长度，您仍可能会看到样本节流。如果您真的不关心消耗了多少 CPU，则设置为 0。

这听起来像 0 意味着不再检查分析采样率，但频率子系统保持运行（？）。

任何人都可以阐明如何使用 freq 完全禁用内核分析吗？ …

我正在尝试在一组独立的 CPU 上运行多线程基准测试。长话短说，我最初尝试使用isolcpus和taskset，但遇到了问题。现在我在玩 cgroups/csets。

我认为“简单”cset shield用例应该可以很好地工作。我有 4 个内核，所以我想使用内核 1-3 进行基准测试（我还将这些内核配置为处于自适应滴答模式），然后内核 0 可用于其他所有内容。

按照这里的教程，它应该很简单：

$ sudo cset shield -c 1-3
cset: --> shielding modified with:
cset: "system" cpuset of CPUSPEC(0) with 105 tasks running
cset: "user" cpuset of CPUSPEC(1-3) with 0 tasks running

所以现在我们有一个隔离的“盾牌”（用户 cset），核心 0 用于其他一切（系统 cset）。

好的，目前看起来不错。现在让我们来看看htop。这些进程应该都已迁移到 CPU 0 上：

嗯？一些进程显示为在屏蔽内核上运行。为了排除 htop 存在错误的情况，我还尝试使用taskset检查显示为在屏蔽中的进程的亲和掩码。

也许那些任务是不可移动的？让我们选择一个显示为在 CPU3 上运行的任意进程（应该在屏蔽中）htop，看看它是否出现在系统 cgroup 中，根据cset：

$ cset shield …

我正在尝试将 Java SDK 8 工具（从 debian backports 存储库安装）设置为默认值。

# update-java-alternatives --list
java-1.7.0-openjdk-amd64 1071 /usr/lib/jvm/java-1.7.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1069 /usr/lib/jvm/java-1.8.0-openjdk-amd64

# update-java-alternatives --set /usr/lib/jvm/java-1.8.0-openjdk-amd64
update-alternatives: error: no alternatives for mozilla-javaplugin.so
update-java-alternatives: plugin alternative does not exist: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so

嗯，除了那个错误（我认为这只是根据https://askubuntu.com/questions/141791/is-there-a-way-to-update-all-java-related-替代方案。如果没有，我不知道如何解决这个问题，因为我可以看到 jdk8 没有 icedtea 插件），这应该可以解决问题，对吧？

但是很多 Java 工具仍然指向 Java 7：

# update-alternatives --get-selections | grep java
appletviewer                   manual   /usr/lib/jvm/java-8-openjdk-amd64/bin/appletviewer
extcheck                       auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/extcheck
idlj                           auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/idlj
jar                            auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/jar
jarsigner                      auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/jarsigner
java                           manual   /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
javac                          auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/javac
javadoc                        auto     /usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc
...

是什么赋予了？破碎的？

编辑：

解决了这个问题： …

我正在使用 Debian 8 amd64 机器进行基准测试。在实验过程中，我希望 CPU 以固定频率（最好是最大可能）运行。这将排除 CPU 时钟速度作为结果变化的来源。

经过一番阅读，似乎正确的做法是将 CPU 调控器更改为performance，这在 Linux 内核文档中描述：

CPUfreq 调控器“性能”将 CPU 静态设置为 scaling_min_freq 和 scaling_max_freq 边界内的最高频率。

遗憾的是，没有提供有关scaling_min_freq和 的更多详细信息scaling_max_freq。希望这无关紧要，因为使用的 CPU 频率是间隔的最大值。

所以我使用 cpufreq-set 启用了这个调控器：

$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
表现
表现
表现
表现

为了更好地衡量，我还在 bios 中禁用了涡轮增压模式：

$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
1

根据以上对性能调节器的描述，我预计 CPU 时钟速度不会出现波动。然而，如果我反复运行cpufreq-info，我会看到时钟速度波动：

$ cpufreq-info | grep '当前 CPU fr'
  当前 CPU 频率为 4.00 GHz。
  当前 CPU 频率为 3.99 GHz。
  当前 CPU 频率为 4.00 GHz。
  当前 CPU …

我们刚刚获得了一台配备 E3-1240 v5 CPU 的戴尔服务器 (PowerEdge R330)：

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 94
model name      : Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz
stepping        : 3
microcode       : 0x9e
cpu MHz         : 3502.916
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes …

首先，让我们检查一下我是否掌握了正确的基础知识：

据我了解，NUMA 系统是 NUMA节点的（非对称）网络，其中 NUMA 节点通常（但并非总是）物理 CPU 包。在NUMA系统中，每个节点都有自己的本地内存，其他节点的内存可以通过总线访问。网络的非一致性意味着获取外部内存会产生不同的成本，具体取决于内存获取中涉及的两个节点的位置。

现在，假设我做对了，下面是真实 Linux 系统的一些输出。

内核支持 NUMA（至少已编译支持）：

$ grep NUMA /boot/config-`uname -r`
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_ARCH_USES_NUMA_PROT_NONE=y
# CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NUMA_EMU=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
CONFIG_ACPI_NUMA=y

但只有一个 NUMA 节点：

$ numactl -H
available: 1 nodes (0)
node 0 cpus: 0 1 2 3
node 0 size: 15955 MB
node 0 free: 5203 MB
node distances:
node   0 
  0:  10 

另请注意，NUMA 总线上只有一条路径，从节点 0 到节点 0（有趣的是距离为 10，而不是 0）。这意味着所有内存访问至少在 NUMA 延迟方面承担相同的成本。

那么，由于只有一个 NUMA 节点，所以这是一台普通的 …