5

我试图了解分支预测器条目何时失效。

以下是我做过的实验:

代码1:

start_measure_branch_mispred()
while(X times):
 if(something something):
  do_useless()
 endif
endwhile
end_measurement()
store_difference()

因此,我多次运行此代码。我可以看到,在第一次运行之后,误预测率降低了。分支预测器学习如何正确预测。但是,如果我一次又一次地运行这个实验(即通过写入./experiment终端),所有的第一次迭代都是从高误预测率开始的。因此,在每次执行时,这些分支预测单元都会conditional branches失效。我正在使用nokaslr并且我已禁用ASLR. 我也在一个独立的核心上运行这个实验。我已经运行了几次这个实验以确保这是行为(即不是因为噪音)。

我的问题是:程序停止执行后 CPU 是否会使分支预测单元失效?或者这是什么原因?

我做的第二个实验是:

代码 2:

do:
    start_measure_branch_mispred()
    while(X times):
      if(something something):
        do_useless()
      endif
    endwhile
    end_measurement()
    store_difference()
while(cpu core == 1)

在这个实验中,我从两个不同的终端运行不同的进程。第一个固定在core 1这样它就可以在核心 1 上运行,它会做这个实验,直到我停止它(通过杀死它)。然后,我从另一个终端运行第二个进程,并将该进程固定到不同的核心。由于这个进程在不同的内核中,它只会执行 do-while 循环 1 次。如果第二个进程被固定到第一个进程的兄弟核心(相同的物理核心),我看到在第一次迭代中,第二个进程几乎正确猜测。如果我将第二个进程固定在另一个不是第一个进程同级的内核上,那么第二个进程的第一次迭代会产生更高的错误预测。这是预期的结果,因为同一物理内核上的虚拟内核共享相同的分支预测单元(这是我的假设)。所以,

据我了解,由于 CPU 没有完成第一个进程(执行繁忙循环的核心 1 进程),分支预测条目仍然存在,第二个进程可以从中受益。但是,在第一个中,从一个运行到另一个运行,我得到了更高的错误预测。

编辑:正如其他用户要求的代码,这里是。您需要从此处下载性能事件标头代码

编译:$(CXX) -std=c++11 -O0 main.cpp -lpthread -o experiment

编码:

#include "linux-perf-events.h"

#include <algorithm>
#include <climits>
#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <vector>

// some array
int arr8[8] = {1,1,0,0,0,1,0,1};

int pin_thread_to_core(int core_id){            
    int retval;     
    int num_cores = sysconf(_SC_NPROCESSORS_ONLN);      
    if (core_id < 0 || core_id >= num_cores)            
        retval = EINVAL;                                
    cpu_set_t cpuset;                                   
    CPU_ZERO(&cpuset);                                  
    CPU_SET(core_id, &cpuset);                          
    retval = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);
    return retval;
}

void measurement(int cpuid, uint64_t howmany, int* branch_misses){

    int retval = pin_thread_to_core(cpuid);
    if(retval){
        printf("Affinity error: %s\n", strerror(errno));
        return;
    }

    std::vector<int> evts;
    evts.push_back(PERF_COUNT_HW_BRANCH_MISSES); // You might have a different performance event!

    LinuxEvents<PERF_TYPE_HARDWARE> unified(evts, cpuid); // You need to change the constructor in the performance counter so that it will count the events in the given cpuid

    uint64_t *buffer = new uint64_t[howmany + 1];
    uint64_t *buffer_org; // for restoring
    buffer_org = buffer;
    uint64_t howmany_org = howmany; // for restoring

    std::vector<unsigned long long> results;
    results.resize(evts.size());

    do{
        for(size_t trial = 0; trial < 10; trial++) {

            unified.start();
            // the while loop will be executed innerloop times
            int res;
            while(howmany){
                res = arr8[howmany & 0x7]; // do the sequence howmany/8 times
                if(res){
                    *buffer++ = res;
                }       
                howmany--;
            }
            unified.end(results);
            // store misses
            branch_misses[trial] = results[0];
            // restore for next iteration
            buffer = buffer_org;
            howmany = howmany_org;
        }
    }while(cpuid == 5); // the core that does busy loop

    // get rid of optimization
    howmany = (howmany + 1) * buffer[3];
    branch_misses[10] = howmany; // last entry is reserved for this dummy operation

    delete[] buffer;

}
void usage(){
    printf("Run with ./experiment X \t where X is the core number\n");
}
int main(int argc, char *argv[]) {
    // as I have 11th core isolated, set affinity to that
    if(argc == 1){
        usage();
        return 1;
    }

    int exp = 16; // howmany

    int results[11];
    int cpuid = atoi(argv[1]); 

    measurement(cpuid, exp, results);

    printf("%d measurements\n", exp);

    printf("Trial\t\t\tBranchMiss\n");
    for (size_t trial = 0; trial < 10; trial++)
    {
        printf("%zu\t\t\t%d\n", trial, results[trial]);
    }
    return 0;
}

如果您想尝试第一个代码,只需运行./experiment 1两次。它将与第一个代码具有相同的执行。

如果您想尝试第二个代码,请打开两个终端,./experiment X在第一个中运行,然后./experiment Y在第二个中运行,其中 X 和 Y 是 cpuid 的。

请注意,您可能没有相同的性能事件计数器。另外,请注意您可能需要更改busyloop 中的cpuid。

4

3 回答 3

2

因此,我进行了更多的实验来减少噪声的影响(无论是从_start直到main()函数还是从syscalls并且interrupts可能发生在两个程序执行之间(系统调用和中断)可能会破坏分支预测器。

这是修改后的实验的伪代码:

int main(int arg){ // arg is the iteration
   pin_thread_to_isolated_core()
   for i=0 to arg:
     measurement()
     std::this_thread::sleep_for(std::chrono::milliseconds(1)); // I put this as it is
   endfor
   printresults() // print after all measurements are completed
}

void measurement(){
   initialization()
   for i=0 to 10:
      start_measurement()
      while(X times) // for the results below, X is 32
        a = arr8[an element] //sequence of 8,
        if(a is odd)
           do_sth()
        endif
      endwhile
      end_measurement()
      store_difference()
   endfor
}

而且,这些是结果:

例如,我将迭代设为 3

Trial           BranchMiss
RUN:1
    0           16
    1           28
    2           3
    3           1
    ....  continues as 1
RUN:2
    0           16   // CPU forgets the sequence
    1           30
    2           2
    3           1
    ....  continues as 1
RUN:3
    0           16
    1           27
    2           4
    3           1
    ....  continues as 1

因此,即使是一毫秒的睡眠也会扰乱分支预测单元。为什么会这样?如果我不在这些测量之间设置睡眠,CPU 可以正确猜测,即 Run2 和 Run3 将如下所示:

RUN:2
    0           1   
    1           1
    ....  continues as 1
RUN:3
    0           1
    1           1
    ....  continues as 1

我相信我从_start测量点减少了分支执行。尽管如此,CPU 还是忘记了经过训练的东西。

于 2019-12-03T19:55:52.673 回答
1

程序停止执行后,CPU 是否会使分支预测单元失效?

不,CPU 不知道程序是否/何时停止执行。

分支预测数据仅对一个虚拟地址空间有意义,因此当您切换到不同的虚拟地址空间时(或者当内核切换到不同的地址空间时,将旧的虚拟地址空间撕开并转换其页表等。回到空闲 RAM,然后在您再次启动程序时构造一个全新的虚拟地址空间)所有旧的分支预测器数据对新的不再有效(完全不同且不相关,即使内容恰好相同)虚拟地址空间。

如果第二个进程被固定到第一个进程的兄弟核心(相同的物理核心),我看到在第一次迭代中,第二个进程几乎正确猜测。

这是预期的结果,因为同一物理内核上的虚拟内核共享相同的分支预测单元(这是我的假设)。

在一个完美的世界里;一个明显的安全漏洞(分支预测器状态,可用于推断导致它的数据的信息,从一个逻辑处理器上的受害者进程泄漏到同一内核中不同逻辑处理器上的攻击者进程)不是什么我会期待的。

这个世界有点不完美。更具体地说,在完美世界中,分支预测器条目将具有“标签”(元数据),其中包含条目有效的虚拟地址空间和完整虚拟地址(以及哪个 CPU 模式),并且将检查所有这些信息在使用条目预测分支之前由 CPU 执行;然而,这比使用较少信息的较小标签更昂贵和更慢,不小心使用了不合适的分支预测器条目,并最终导致“幽灵般的”安全漏洞。

请注意,这是您使用的操作系统未能缓解的已知漏洞,很可能是因为您禁用了针对此类漏洞的第一道防线 (ASLR)。

于 2019-12-02T19:57:24.240 回答
1

TL:DR:省电深度睡眠状态清除分支预测器历史记录。将睡眠水平限制为 C3 可将其保留在 Broadwell 上。从广义上讲,包括 BTB 和 RSB 在内的所有分支预测状态都保存在 C3 和更浅的位置。

为了使分支历史在运行中有用,它还有助于禁用 ASLR(因此虚拟地址相同),例如使用非 PIE 可执行文件。

此外,将进程隔离在单个内核上,因为分支预测器条目对于 Intel CPU 上的物理内核是本地的。不过,核心隔离并不是绝对必要的。如果您在一个大部分空闲的系统上连续多次运行该程序,您会发现有时它可以工作,但并非总是如此。基本上,任何碰巧在同一个核心上运行的任务,即使是很短的时间,也会污染分支预测器状态。因此,在独立内核上运行有助于获得更稳定的结果,尤其是在繁忙的系统上。


有几个因素会影响测量到的分支错误预测的数量,但可以将它们相互隔离以确定导致这些错误预测的原因。在讨论细节之前,我需要先介绍一些术语和我的实验设置。

我将使用您发布的答案中的代码版本,它比问题中显示的更通用。以下代码显示了最重要的部分:

void measurement(int cpuid, uint64_t howmany, int* branch_misses) {
    ...
        for(size_t trial = 0; trial < 4; trial++) {

            unified.start();
            int res;
            for(uint64_t tmp = howmany; tmp; tmp--) {
                res = arr8[tmp & 0x7];
                if(res){
                    *buffer++ = res;
                }
            }
            unified.end(results);
            ...
        }
    ...
}

int main(int argc, char *argv[]) {
    ...
    for(int i = 0; i < 3; ++i) {
        measurement(cpuid, exp, results);
        std::this_thread::sleep_for(std::chrono::milliseconds(1));
    }
    ...
}

该程序的单次执行对函数BR_MISP_RETIRED.ALL_BRANCHES中 while 循环的分支错误预测(Intel 处理器上的事件)的数量进行多组测量。measurement每组测量后都会调用sleep_for()休眠 1ms。同一组内的测量仅通过调用unified.start()和分隔unified.end(),它们在内部执行到内核模式和返回用户模式的转换。我已经通过实验确定,一个集合中的测量数量为 4 并且集合的数量为 3 就足够了,因为分支错误预测的数量不会超出此范围。此外,调用的确切位置pin_thread_to_core在代码中似乎并不重要,这表明围绕感兴趣区域的代码没有污染。

在我所有的实验中,我使用 gcc 7.4.0 -O0 编译了代码,并在具有 Linux 4.15.0 和禁用超线程的 Intel Broadwell 处理器的系统上本地运行它。正如我稍后将讨论的,重要的是查看感兴趣区域中存在哪些类型的分支(即,正在测量分支错误预测数量的代码)。由于您已将事件计数限制为仅用户模式事件(通过设置perf_event_attr.exclude_kernel为 1),因此您只需考虑用户模式代码。但是使用 -O0 优化级别和 C++ 会使本机代码有点难看。

unified.start()函数包含两次调用,ioctl()但仅在从第二次调用返回后才测量用户模式事件。从 中的那个位置开始unified.start(),有一堆calls 到 PLT(仅包含无条件直接跳转),一些直接跳转,ret最后是 a。while 循环被实现为一对有条件和无条件的直接跳转。然后调用unified.end(),调用ioctl转换到内核模式并禁用事件计数。在整个感兴趣区域中,除了单个ret. 任何ret或者条件跳转指令可能会产生分支预测错误事件。间接跳转和调用也会产生错误预测事件(如果它们存在的话)。了解这一点很重要,因为活动的 Spectre v2 缓解可以更改用于预测非rets 的间接分支的缓冲区的状态(称为 BTB)。根据内核日志,系统上使用了以下 Spectre 缓解措施:

Spectre V1:缓解:usercopy/swapgs 屏障和 __user 指针清理 Spectre V2:缓解:完整的通用 retpoline
Spectre V2:Spectre v2 / SpectreRSB 缓解:在上下文切换上填充 RSB
Spectre V2:启用固件调用的受限推测
Spectre V2:缓解:启用条件间接分支预测障碍

上述实验设置是基线设置。下面讨论的一些实验使用额外的编译选项或内核参数。首先,我使用intel_idle.max_cstate来限制内核可以使用的最深核心 C 状态。Broadwell 支持以下核心 C 状态:C0、C1、C1E、C3、C6 和 C7。我只需要使用两个max_cstate值,即 3 和 6,这样内核就不会分别使用低于 C3 和 C6 的核心 C 状态。一些实验是在与isolcpus内核参数隔离的内核上运行的。-no-pie最后,一些实验使用使用禁用 PIE的选项编译的代码。所有其他内核参数都具有默认值。特别是,始终启用 CPU 漏洞缓解措施。

下图显示了在不同配置中测得的误判数量。我遵循了以下实验方法:

  • 根据需要配置系统以进行实验。然后重新启动系统,使分支预测缓冲区的状态与其他实验所使用的状态相同。
  • 该程序在终端上连续运行十次。如果isolcpus在配置中使用,则程序始终在隔离内核上运行。
  • 十次运行中的每一次都有三组四次测量。第一次运行第一组的四次测量图中未显示,因为所有配置中的数字实际上都相同。它们基本上是 15、6、3 和 2 次错误预测。这些是分支预测器的训练运行,因此预计第一次测量的错误预测数量会很高,并且随着分支预测器的学习,它会在以后的测量中减少。增加同一组中的测量数量不会进一步减少错误预测的数量。其余的测量值绘制在图中。每种配置的 12 个条形对应于以相同顺序在单次运行中执行的 12 次测量。这些数字是十次运行的平均值(除了第一次运行的第一组的数字不包括在前四个柱的平均值中)。标签sXmY图中是指在 10 次运行中对集合 X 的测量 Y 的平均错误预测数。

在此处输入图像描述

第一种配置本质上等同于默认配置。第一组的第一次测量表明分支预测器是否保留了它在之前的实验运行中学到的东西。其他两组的第一次测量表明分支预测器是否保留了它在同一运行中的前一组测量中学到的知识,尽管调用了sleep_for. 很明显,分支预测器在第一个配置中的两种情况下都未能保留此信息。在接下来的三个配置中也是如此。在所有这些配置中,intel_idle.max_cstate设置为 6,这意味着 cpuidle 子系统可以选择在具有空运行队列时将内核放入 C6。这是意料之中的,因为 C6 处于电源门控状态。

在第五种配置中,intel_idle.max_cstate设置为 3,意味着内核允许使用的最深的 C 状态是 C3,这是一个时钟门控状态。结果表明分支预测器现在可以在对 的调用中保留其信息sleep_for。使用类似的工具strace,您可以确认sleep_for始终调用nanosleep系统调用而不管intel_idle.max_cstate. 这意味着用户内核转换不能成为污染先前配置中的分支预测历史的原因,并且 C 状态必须是这里的影响因素。

Broadwell 支持 C 状态的自动升级和降级,这意味着硬件本身可以将 C 状态更改为不同于内核请求的状态。如果没有禁用这些功能,结果可能会有些不安,但我认为这不是问题。我观察到在 C3 或 C6 中花费的周期数(取决于intel_idle.max_cstate)随着测量组的数量而增加。

在第五种配置中,第一个条与之前的配置一样高。所以分支预测器仍然无法记住它在第一次运行中学到了什么。第六和第七种配置类似。

在第八种配置中,第一个条形显着低于早期配置,这表明分支预测器现在可以受益于它在之前运行相同程序中学到的知识。这是通过使用除了设置之外的两个配置选项来实现的intel_idle.max_cstate到 3:禁用 PIE 并在隔离内核上运行。虽然从图中不清楚,但这两个选项都是必需的。内核可以随机化 PIE 二进制文件的基地址,从而改变所有分支指令的地址。这使得相同的静态分支指令更有可能映射到不同的分支缓冲区条目,而不是之前的运行。所以分支预测器在之前的运行中学到的东西仍然存在于它的缓冲区中,但它不能再利用这些信息,因为分支的线性地址已经改变。必须在隔离内核上运行这一事实表明内核在空闲内核上运行短任务是很常见的,这会污染分支预测器状态。

八种配置的前四个条形显示分支预测器仍在学习感兴趣区域中的一个或两个分支指令。实际上,所有剩余的分支错误预测都不适用于 while 循环中的分支。为了表明,可以在相同的代码上重复实验,但没有 while 循环(即,unified.start()和之间没有任何内容unified.end())。这是第九种配置。观察错误预测的数量是如何大致相同的。

第一个酒吧仍然比其他酒吧高一点。此外,分支预测器似乎很难预测某些分支。第十种配置-no-pie更进一步,完全禁用了 ASLR。这使得第一个栏与其他栏大致相等,但并没有消除两个错误预测。perf record -e cpu/branch-misses/uppp -c 1可用于找出哪些分支被错误预测。它告诉我,感兴趣区域中唯一被错误预测的分支是ioctl. 我不确定哪两个分支被错误预测以及为什么。

关于在超线程之间共享分支预测条目,我们知道一些缓冲区是共享的。例如,我们从Spectre攻击中得知,至少在某些 Intel 处理器上的超线程之间共享 BTB。据英特尔称:

如“间接分支预测和英特尔® 超线程技术(英特尔® HT 技术)”的描述中所述,共享一个内核的逻辑处理器可以共享间接分支预测器,允许一个逻辑处理器控制另一个逻辑处理器的间接分支的预测目标同一个核心。. . .
回想一下,间接分支预测器永远不会跨内核共享。

您的结果还表明 BHT 是共享的。我们也知道 RSB 不是共享的。一般来说,这是一种设计选择。这些结构不必是那样的。

于 2019-12-24T14:38:56.937 回答