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

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

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

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

解决方法

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

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

脚注 1：还要注意 clwb on Cascade Lake works like clflushopt - it just evicts。所以 store + clwb + mfence in a loop test 将测试缓存冷的情况，如果你没有在定时间隔之前做一些事情来加载行。（从论文的描述来看，我认为他们确实如此）。未来的 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成为瓶颈，造成阻塞，测得的延迟不准确？

是的，这是我的猜测。

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

我不知道，抱歉。