Intel 的 Optane 持久内存上的 `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 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;
}

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

Answer 1

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

这与直接使用 Optane 芯片本身不同；内存控制器的 Write Pending Queue (WPQ) 是 Cascade Lake Intel CPU 上的持久域的一部分，就像您的一样； wikichip quotes an Intel image:

脚注 1：另请注意。因此，循环测试中的 store + clwb + mfence 将测试缓存冷的情况，如果您不执行某些操作以在定时间隔之前加载该行。（从论文的描述来看，我认为是的）。未来的 CPU 将有望 正确地 支持 clwb，但至少 CSL 得到了支持的指令，因此未来的库将不必检查 CPU 功能在使用之前。

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

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

有趣的事实：英特尔 CPU 的后代 () 甚至在持久域中都有缓存（L3？），希望 clwb 更便宜。 IDK 如果这会影响到同一位置的背靠背 movnti 吞吐量，甚至 clflushopt.

During the test, did the Write Pending Queue of CPU's iMC or the WC buffer in the optane PM become the bottleneck, causing blockage, and the measured latency has been inaccurate?

是的，这是我的猜测。

If this is the case, is there a tool to detect it?

我不知道，抱歉。

Answer 2

主要原因是重复刷新到同一个缓存行被显着延迟[1]。
您正在测试平均延迟，而不是像 FAST20 论文那样的 best-case 延迟。
ntstore 比clwb 贵，所以它的延迟更高。我猜你的第一段打错了。

附加在 4.14

问：检测缓冲区 WPQ 上可能存在的瓶颈的工具？
A：可以在PM空闲的时候得到一个baseline，用这个baseline来表示可能的瓶颈。
工具：

英特尔内存带宽监控
从处理器中的性能监控单元 (PMU) 读取两个硬件计数器：1) UNC_M_PMM_WPQ_OCCUPANCY.ALL，它计算每个周期的 WPQ 条目的累积数量和 2) UNC_M_PMM_WPQ_INSERTS，它计算有多少条目已插入 WPQ。并计算WPQ的排队延迟：UNC_M_PMM_WPQ_OCCUPANCY.ALL / UNC_M_PMM_WPQ_INSERTS。 [2]

[1]陈友民等。 “Flatstore：一种高效的 log-structured key-value 持久内存存储引擎。” Twenty-Fifth 编程语言和操作系统架构支持国际会议论文集。 2020.
[2] 今村、聪和吉田英二。 “分析 inter-process 对混合内存系统的干扰。” Asia-Pacific 地区研讨会的高性能计算国际会议论文集。 2020.

Intel 的 Optane 持久内存上的 `clwb` 和 `ntstore` 的延迟是多少？

What is the latency of `clwb` and `ntstore` on Intel's Optane Persistent Memory?

x86-64

intel

cpu-architecture

persistent-memory