是否有人知道尝试在 App Direct 模式（即作为非易失性内存）中使用 Intel Optane DC Memory (DCPMM) 使用直写 (WT) 或 Un-可缓存 (UC) 内存策略？这个想法是将常规内存用作非易失性（在发生故障时数据不会丢失），脏缓存行并不理想，因为它是易失性的。有多个链接显示使用写回 (WB) 或写组合 (WC) 与非临时访问 (NTA) 指令的示例，也使用 WB 和 CLFLUSHOPT 或 CLWB 写指令。与 WB/WC 相比，在使用 WT/UC 时没有将整个缓存行写入内存，除了带宽之外还有其他重要的缺点吗？
【问题讨论】：
标签： x86 intel cpu-cache persistent-storage persistent-memory
（这主要是猜测，我没有使用 Optane DC PM 进行任何性能测试，只是偶尔阅读有关 DRAM 的 UC 或 WT。但我认为对于它们的一般工作方式已经足够了解，可以说这可能是对于许多工作负载来说是个坏主意。）
进一步了解 Optane DC PM DIMM：https://thememoryguy.com/whats-inside-an-optane-dimm/ - 它们包括像 SSD 一样的磨损均衡重新映射层。
还相关：英特尔论坛上的When I test AEP memory, I found that flushing a cacheline repeatedly has a higher latency than flushing different cachelines. I want to know what caused this phenomenon. Is it wear leveling mechanism ?。这表明重复写入同一缓存行可能比您预期的还要糟糕。
我认为，UC 还意味着强排序会伤害 OoO 执行官。我认为 UC 还会阻止您使用 NT 存储进行全行写入。它还会完全破坏读取性能，所以我认为不值得考虑。
WT 可能值得考虑作为clwb 的替代品（假设它实际上适用于 NV 内存），但您仍然必须小心存储的编译时重新排序。 _mm_clwb 可能是一个可以防止此类问题的编译器内存屏障。
不过，在存储繁重的工作负载中，您会预计写入速度会严重下降。每核内存带宽受到未完成请求数量的极大限制。使每个请求更小（只有 8 个字节或其他内容而不是一整行）不会使其明显更快。绝大多数时间是通过内存层次结构获取请求，并等待地址线选择正确的位置，而不是内存总线上的实际突发传输。 （这是流水线的，因此对于同一个 DRAM 页面的多个全线请求，内存控制器可以将大部分时间用于传输数据，而不是等待，我认为。Optane / 3DXPoint 不如 DRAM 快，因此可能需要更多等待.)
因此，例如，存储连续的int64_t 或double 将需要每个 64 字节缓存行 8 个单独的存储，除非您（或编译器）矢量化。使用 WT 而不是 WB + clwb，我猜这会慢 8 倍。 这不是基于任何关于 Optane DC PM 的真实性能细节；我没有看到内存延迟/带宽数字，也没有看过 WT 性能。不过，我偶尔会看到一些论文比较了合成工作负载与 WT 与 WB 在常规 DDR DRAM 上的真实英特尔硬件上的缓存。如果您的代码不典型地多次写入同一缓存行，我认为它是可用的。 （但通常这是您想要做和优化的事情，因为 WB 缓存使其非常便宜。）
如果您有 AVX512，则可以进行全行 64 字节存储，前提是确保它们对齐。 （无论如何，您通常都希望获得 512 位向量的性能）。
【讨论】：