Question

我正在考虑执行以下操作：

编写一个守护进程，该进程创建约50KB的参考数据并将其存储在共享内存中的数组中。
守护程序进程会将其亲缘关系设置为套接字上的一个核心，并将定期在参考数据的第64个字节的地址上调用__builtin_prefetch()，以将所有参考数据都保留在L3缓存中进程在同一套接字上的其他内核上运行。
每秒多次，应用程序进程将索引到数组中以检索当时所需的任何参考数据。由于数据将存储在L3缓存中，因此访问时间将相对较快。

我认为我不是第一个提出这种想法的人。有人可以就我可能遇到的限制提供建议吗？例如，在守护进程中考虑以下伪代码，以将参考数据保留在缓存中：

for (size_t i = 0; i < sizeof(referenceData); i += 64) {
    __builtin_prefetch(i + (void*)&referenceData);
}

对于50KB的参考数据，上述循环将快速连续调用__builtin_prefetch() 800次。这样做是否会引起问题，例如其他应用程序尝试访问内存（参考数据除外）时的等待时间高峰？如果是这样，我可以在for循环中插入sleep语句：

for (size_t i = 0; i < sizeof(referenceData); i += 64) {
    __builtin_prefetch(i + (char*)&referenceData);
    if (i % (64*10)) { // sleep every 10th time around the loop
        sleep_briefly();
    }
}

建议和指向相关文档来源的链接。

编辑以根据评论添加其他信息：

参考数据将保持不变。其他进程将访问在应用程序级事件中的一小部分数据：大概是数据中有7个索引，每个索引检索4个字节，因此每个事件检索约28个字节。
我认为无法预测最有可能访问哪些数据条目，因此我想将整个参考数据保留在缓存中，而不仅仅是其中的一小部分。
如果延迟无关紧要，则不需要缓存的参考数据，因为每个应用程序可以根据需要为每个事件重新计算所需的任何内容。但是，响应事件的延迟确实很重要。
我还没有开发所有的应用程序代码，但是我希望在没有这种优化的情况下，“响应事件”时间少于200ns。如果优化效果良好，则可以将“响应事件”的时间减少到不到100ns。
事件可能每秒发生几百次或每隔几秒钟一次。因此，我担心的是，如果未主动将参考数据保留在缓存中，则由于缺乏使用，偶尔会将其从缓存中清除。

Answer 1

一种更好，更简单的解决方案是让参考数据的用户提前加载/缓存认为合适的数据。

您占用CPU缓存的过程看起来根本不合理。

在Intel上，您可以使用Cache Allocation Technology为您的应用程序保留一定数量的L3缓存。

预取大量参考数据的实际限制

1 个答案: