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

Question

In this paper，据说optane PM的clwb和ntstore的8字节顺序写入延迟分别为90ns和62ns，顺序读取为169ns。

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

在测试过程中，CPU 的 iMC 的 Write Pending Queue 或 optane PM 中的 WC 缓冲区是否成为瓶颈，导致阻塞，测量的延迟不准确？如果是这种情况，有没有检测工具？

#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;
}

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

Answer 1

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

这与一直到 Optane 芯片本身不同；内存控制器的写入挂起队列 (WPQ) 是 Cascade Lake Intel CPU 上持久性域的一部分，例如您的 CPU； wikichip quotes an Intel image:

脚注 1：还要注意 clwb on Cascade Lake works like clflushopt - it just evicts。所以 store + clwb + mfence 在循环测试中会测试缓存冷的情况，如果你不做任何事情来加载定时间隔之前的行。 （从论文的描述来看，我认为他们确实如此）。未来的 CPU 希望正确支持clwb，但至少 CSL 得到了支持的指令，因此未来的库在使用它之前不必检查 CPU 功能。

---

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

除此之外，例如，重复重写同一行似乎比顺序写入要慢。这个Intel forum post 报告“重复刷新高速缓存行”的“延迟更高”，而不是刷新不同的高速缓存行。 （DIMM 内的控制器确实会进行磨损均衡，顺便说一句。）

有趣的事实：下一代 Intel CPU (perhaps CPL or ICX) 将在持久域中甚至拥有缓存 (L3?)，希望使 clwb 更便宜。 IDK 如果这会影响到同一位置的背靠背movnti 吞吐量，甚至clflushopt。

---

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

是的，这是我的猜测。

如果是这种情况，有没有检测工具？

我不知道，对不起。