迁移到 64 位操作系统时共享内存性能下降答案

【问题标题】：Slow shared memory performance when moved to 64-bit OS迁移到 64 位操作系统时共享内存性能下降
【发布时间】：2011-04-07 22:18:50
【问题描述】：

我遇到了在 64 位 Windows 上运行的 32 位旧版应用程序的问题。有问题的应用程序使用 CreateFileMapping 创建共享内存。当它在 64 位 Windows 上运行时，从另一个进程访问此共享内存的任何尝试大约需要 1 秒。共享内存是使用页面保护标志创建的：

flProtect = PAGE_READONLY | SEC_NOCACHE | SEC_COMMIT;

当使用相同的内存创建时：

flProtect = PAGE_READONLY | SEC_COMMIT;

问题消失了。目前这种解决方法是可以接受的，但我们确实有一些设备需要设置 SEC_NOCACHE 标志。

有人能告诉我为什么 SEC_NOCACHE 在这种情况下会影响性能吗？

更新：似乎只写入此缓冲区已增加到 1000 毫秒。阅读似乎没有受到影响。这次我们正在向缓冲区写入大约 5MB。

Update2：该软件用于许多系统，其中一个系统具有需要使用此标志的物理设备。我们目前仅限于使用此设备在 32 位窗口中运行机器。

【问题讨论】：

【解决方案1】：

以下是Microsoft 对该标志的评价：

SEC_NOCACHE 标志用于需要各种架构的锁定结构位于从未被提取的内存 CPU 缓存。在 x86 和 MIPS 上机器，使用这个标志只会减慢性能下降，因为硬件使缓存保持一致。

不幸的是，他们没有量化减速的数量。

【讨论】：

这是真的，但是在 32 位中，这种减速小于 10 毫秒。在 64 中它在 1000ms 的范围内。
@Justin：这两个进程都是 32 位的吗？至少在 *NIX 上，共享内存由 32 位进程创建，从 64 位进程访问，反之亦然。顺便说一句，如果引用的文章背后有任何真相，那么请扔掉标志：Windows 现在运行的所有多 CPU/核心系统都是明确的缓存一致的（与十多年前运行 WinNT 3.5 的第一个 SMP 系统不同）。
@Dummy：两个进程都是 32 位的。感谢多核点，我会调查的。我们使用的只有一个硬件需要这个标志，它用于 32 位系统。目前我们检查操作系统是 32 还是 64 并设置标志。我只是好奇这种减速的根本原因。

【解决方案2】：

您正在使用该标志禁用文件系统缓存。是的，这产生了巨大的不同，它迫使操作系统使用磁盘驱动程序并直接读取扇区。无法读取和缓存圆柱体，从而禁用了使读取磁道而无需移动读取头如此便宜的优化。并且延迟回写被禁用，这是一种使磁盘写入看起来是即时的优化。

【讨论】：

【解决方案3】：

我猜，因为内存必须从 64 位重新映射到 32 位，所以提供“反弹”缓冲区会变得很昂贵。启用缓存后，此反弹缓冲区是隐式的，操作系统可能会规避不断更新内存部分的需要。

【讨论】：

这是我的倾向，但 1000 毫秒对于这些操作来说似乎是过多的时间。
只有 DMA 硬件需要反弹缓冲区，它需要一个 32 位的物理地址。在用户模式下的 32 位应用程序中，由 MMU 完成转换，内存中的任何地址，甚至超过 4GB，都可以映射到 32 位虚拟地址。
@ben：即使没有反弹缓冲区，从 64 位到 32 位的映射也会增加这种开销吗？
不，MMU 在 32 位操作系统上的使用方式完全相同。