时间戳

首页 > 解决方案 > Intel Optane Persistent Memory 上 `clwb` 和 `ntstore` 的延迟是多少？

x86-64 - Intel Optane Persistent Memory 上 `clwb` 和 `ntstore` 的延迟是多少？

问题描述

在本文中，Optane PM的 8 字节顺序写入clwb和ntstoreoptane PM 的 8 字节顺序写入延迟分别为 90ns 和 62ns，顺序读取为 169ns。

但是在我使用 Intel 5218R CPU 的测试中，clwb大约是 700ns，ntstore大约是 1200ns。当然，我的测试方法和论文是有区别的，但是结果太差了，不合理。而且我的测试更接近实际使用情况。

测试的时候是不是CPU的iMC的Write Pending Queue或者optane PM中的WC buffer成为了瓶颈，导致阻塞，测得的延迟不准确？如果是这种情况，是否有工具可以检测到它？

#include "libpmem.h"
#include "stdio.h"
#include "x86intrin.h"

//gcc aep_test.c -o aep_test -O3 -mclwb -lpmem

int main()
{
    size_t mapped_len;
    char str[32];
    int is_pmem;
    sprintf(str, "/mnt/pmem/pmmap_file_1");
    int64_t *p = pmem_map_file(str, 4096 * 1024 * 128, PMEM_FILE_CREATE, 0666, &mapped_len, &is_pmem);
    if (p == NULL)
    {
        printf("map file fail!");
        exit(1);
    }
    if (!is_pmem)
    {
        printf("map file fail!");
        exit(1);
    }

    struct timeval start;
    struct timeval end;
    unsigned long diff;
    int loop_num = 10000;

    _mm_mfence();
    gettimeofday(&start, NULL);

    for (int i = 0; i < loop_num; i++)
    {
        p[i] = 0x2222;
        _mm_clwb(p + i);
        // _mm_stream_si64(p + i, 0x2222);
        _mm_sfence();
    }

    gettimeofday(&end, NULL);

    diff = 1000000 * (end.tv_sec - start.tv_sec) + end.tv_usec - start.tv_usec;

    printf("Total time is %ld us\n", diff);
    printf("Latency is %ld ns\n", diff * 1000 / loop_num);

    return 0;
}

非常感谢任何帮助或更正！

标签： x86-64intelcpu-architecturepersistent-memory

解决方案

https://www.usenix.org/system/files/fast20-yang.pdf描述了他们正在测量的内容：做一个存储的 CPU 端 + clwb + mfence 用于缓存写入1。因此，将存储“接受”为持久的 CPU 管道延迟。

这与一直到 Optane 芯片本身不同。内存控制器的写入挂起队列 (WPQ) 是 Cascade Lake Intel CPU 上持久性域的一部分，例如您的 CPU；wikichip 引用了一张英特尔图片：

在此处输入图像描述

脚注 1：另请注意，clwb在 Cascade Lake 上的工作方式类似于clflushopt- 它只是驱逐. 所以 store + clwb + mfence 在循环测试中会测试缓存冷的情况，如果你不做任何事情来加载定时间隔之前的行。（从论文的描述来看，我认为他们确实如此）。未来的 CPU 有望正确支持clwb，但至少 CSL 得到了支持的指令，因此未来的库在使用它之前不必检查 CPU 功能。

您正在执行许多存储，这将填满内存控制器或内存层次结构中其他位置的任何缓冲区。因此，您正在测量循环的吞吐量，而不是一个存储的延迟加上 mfence 本身在先前空闲的 CPU 管道中。

除此之外，例如，重复重写同一行似乎比顺序写入慢。这篇英特尔论坛帖子报告了“重复刷新缓存线”的“延迟更高”，而不是刷新不同的缓存线。（DIMM 内的控制器确实会进行磨损均衡，顺便说一句。）

有趣的事实：后几代的英特尔 CPU（可能是 CPL 或 ICX）将在持久性域中甚至拥有缓存（L3？），希望能clwb更便宜。如果这会影响到同一位置的背靠背movnti吞吐量，那么 IDK 甚至clflushopt.

测试的时候是不是CPU的iMC的Write Pending Queue或者optane PM中的WC buffer成为了瓶颈，导致阻塞，测得的延迟不准确？

是的，这将是我的猜测。

如果是这种情况，是否有工具可以检测到它？

我不知道，对不起。

推荐阅读