19

我在 x86_64 系统上遇到了从 Linux 内核 3.11 到 3.12 的奇怪性能回归。在 Fedora 20 3.12 上运行Mark Stock 的 Radiance 基准测试明显变慢。没有其他任何改变 - 相同的二进制文件，相同的 glibc - 我只是启动了不同的内核版本，性能发生了变化。定时程序 rpict 是 100% CPU 绑定的用户级代码。

在我将此报告为错误之前，我想找出导致此行为的原因。我对 Linux 内核了解不多，从 3.11 到 3.12 的更改日志也没有给我任何线索。

我在两个系统上观察到这一点，一个 Intel Haswell (i7-4771) 和一个 AMD Richland (A8-6600K)。在 Haswell 系统上，用户时间从 3.11 的 895 秒变为 3.12 的 962 秒。在里奇兰，从 1764 年到 1844 年。这些时间可以在几秒钟内重复。

我用 perf 做了一些分析，发现 IPC 的下降与减速的比例相同。在 Haswell 系统上，这似乎是由于更多错过的分支造成的，但为什么预测率会下降呢？Radiance 确实使用了随机数生成器——“更好”的随机性会导致丢失的分支吗？但除了 OMAP4 支持之外，RNG 在 3.12 中似乎不需要更改。

在 AMD 系统上，perf 只是指向更多的空闲后端周期，但原因尚不清楚。

哈斯韦尔系统：

3.11.10  895s user, 3.74% branch-misses, 1.65 insns per cycle
3.12.6   962s user, 4.22% branch-misses, 1.52 insns per cycle

里奇兰系统：

3.11.10  1764s user, 8.23% branch-misses, 0.75 insns per cycle
3.12.6   1844s user, 8.26% branch-misses, 0.72 insns per cycle

我还查看了两个内核的 dmesg 输出的差异，但没有看到任何可能导致 CPU 密集型程序如此缓慢的任何东西。

我尝试将cpufreq调节器从默认的按需切换到性能，但这没有任何效果。

可执行文件是使用 gcc 4.7.3 编译的，但没有使用 AVX 指令。libm 似乎仍然使用一些 AVX（例如__ieee754_pow_fma4），但这些函数仅占总执行时间的 0.3%。

附加信息：

有什么想法（除了将内核更改一分为二）？

4

2 回答 2

8

让我们检查您的perf stat输出： http: //www.chr-breitkopf.de/tmp/perf-stat.A8.txt

内核 3.11.10

    1805057.522096 task-clock                #    0.999 CPUs utilized          
           183,822 context-switches          #    0.102 K/sec                  
               109 cpu-migrations            #    0.000 K/sec                  
            40,451 page-faults               #    0.022 K/sec                  
 7,523,630,814,458 cycles                    #    4.168 GHz                     [83.31%]
   628,027,409,355 stalled-cycles-frontend   #    8.35% frontend cycles idle    [83.34%]
 2,688,621,128,444 stalled-cycles-backend    #   35.74% backend  cycles idle    [33.35%]
 5,607,337,995,118 instructions              #    0.75  insns per cycle        
                                             #    0.48  stalled cycles per insn [50.01%]
   825,679,208,404 branches                  #  457.425 M/sec                   [66.67%]
    67,984,693,354 branch-misses             #    8.23% of all branches         [83.33%]

    1806.804220050 seconds time elapsed

内核 3.12.6

    1875709.455321 task-clock                #    0.999 CPUs utilized          
           192,425 context-switches          #    0.103 K/sec                  
               133 cpu-migrations            #    0.000 K/sec                  
            40,356 page-faults               #    0.022 K/sec                  
 7,822,017,368,073 cycles                    #    4.170 GHz                     [83.31%]
   634,535,174,769 stalled-cycles-frontend   #    8.11% frontend cycles idle    [83.34%]
 2,949,638,742,734 stalled-cycles-backend    #   37.71% backend  cycles idle    [33.35%]
 5,607,926,276,713 instructions              #    0.72  insns per cycle        
                                             #    0.53  stalled cycles per insn [50.01%]
   825,760,510,232 branches                  #  440.239 M/sec                   [66.67%]
    68,205,868,246 branch-misses             #    8.26% of all branches         [83.33%]

    1877.263511002 seconds time elapsed

3.12.6 在“周期”字段中还有近 300 个 Gcycle；只有 6,5 个 Gcycles 是前端的停顿，而 261 个 Gcycles 是在后端停顿的。您只有 0,2 G 的额外分支未命中（每个花费大约 20 个周期 - 每个 optim.manual 第 597 页；所以 4Gcycles），所以我认为您的性能问题与内存子系统问题有关（更现实的后端事件，它可以受内核影响）。页面错误差异和迁移计数很低，我认为它们不会直接减慢测试速度（但迁移可能会将程序移动到更糟糕的地方）。

您应该更深入地了解perf计数器以找到问题的确切类型（如果您的测试运行时间较短，这将更容易）。英特尔手册http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf将为您提供帮助。查看第 587 页 (B.3.2) 了解整体事件层次结构（FE 和 BE 停顿也在这里），B.3.2.1-B.3.2.3 了解有关后端停顿以及如何开始挖掘的信息（检查缓存事件等） ) 及以下。

内核如何影响内存子系统？它可以设置不同的虚拟到物理的映射（几乎不是你的情况），或者它可以将过程移离数据更远。您没有 NUMA 机器，但 Haswell 不是确切的 UMA - 有一个环形总线，一些内核更接近内存控制器或共享 LLC（最后一级缓存）的某些部分。您可以使用taskset实用程序测试您的程序，将其绑定到某个内核 - 内核不会将其移动到其他内核。

更新：在检查了来自 A8 的新性能统计信息后，我们发现 3.12.6 有更多的 DLTB 未命中。随着 /proc/pid/maps 的变化（很多短[heap]节而不是 single [heap]，仍然没有确切的信息为什么），我认为透明大页（THP）可能存在差异；对于 2M 大页，相同所需的 TLB 条目更少内存量和更少的 tlb 未命中），例如在 3.12 中，由于堆段短，它无法应用。

您可以检查您的/proc/PID/smapsforAnonHugePages和/proc/vmstatfor thp* 值以查看 thp 结果。此处记录了值 kernel.org/doc/Documentation/vm/transhuge.txt

@osgx 你找到了原因！在 echo never > /sys/kernel/mm/transparent_hugepage/enabled 之后，3.11.10 和 3.12.6 一样长！

好消息！

关于如何禁用随机化以及在何处将其报告为错误（7% 的性能回归非常严重）的附加信息将不胜感激

我错了，这种多堆部分效果不是 brk 随机化（它只改变堆的开头）。这是VMA合并失败do_brk；不知道为什么，但是mm在 3.11.10 - 3.12.6 之间看到了 VM_SOFTDIRTY 的一些变化。

UPDATE2：未合并 VMA 的可能原因：

http://lxr.missinglinkelectronics.com/linux+v3.11/mm/mmap.c#L2580 do_brk 在 3.11

http://lxr.missinglinkelectronics.com/linux+v3.11/mm/mmap.c#L2577 do_brk 在 3.12

3.12 刚刚添加在末尾do_brk

2663        vma->vm_flags |= VM_SOFTDIRTY;
2664        return addr;

上面我们有

2635        /* Can we just expand an old private anonymous mapping? */
2636        vma = vma_merge(mm, prev, addr, addr + len, flags,
2637                                        NULL, NULL, pgoff, NULL);

里面vma_merge有 vm_flags 的测试

http://lxr.missinglinkelectronics.com/linux+v3.11/mm/mmap.c#L994 3.11

http://lxr.missinglinkelectronics.com/linux+v3.12/mm/mmap.c#L994 3.12

1004        /*
1005         * We later require that vma->vm_flags == vm_flags,
1006         * so this tests vma->vm_flags & VM_SPECIAL, too.
1007         */

vma_merge --> can_vma_merge_before --> is_mergeable_vma ...

 898        if (vma->vm_flags ^ vm_flags)
 899                return 0;

但是在检查时，新的 vma 没有被标记为 VM_SOFTDIRTY，而旧的 vma 已经被标记了。

于 2014-01-15T22:56:43.613 回答
0

这种变化可能是一个可能的候选http://marc.info/?l=linux-kernel&m=138012715018064。我松散地说，因为我没有资源来确认。值得注意的是，这是3.11.10 和 3.12.6 之间调度程序的唯一重大变化。

无论如何，我很想看到你的调查结果的最终结果，所以请随时通知我们。

于 2014-01-15T22:49:57.150 回答