移动到64位操作系统时的共享内存性能降低

我在运行64位窗口的32位旧版应用程序时遇到问题。有问题的应用程序使用CreateFileMapping创建共享内存。当它在64位Windows上运行时，从另一个进程访问此共享内存的任何尝试都需要大约1秒的时间。共享内存使用页面保护标志创建：移动到64位操作系统时的共享内存性能降低

flProtect = PAGE_READONLY | SEC_NOCACHE | SEC_COMMIT;

使用创建相同的内存时：

flProtect = PAGE_READONLY | SEC_COMMIT;

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

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

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

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

来源

2010-09-03 Justin

'SEC_NOCACHE'：*应用程序不应该使用此属性，除非设备明确需要。*是否有任何理由使用此标志？你（或最初的实施者）是否误解了它的目的？ – peterchen 2010-09-04 09:21:34

我们有一个需要设置此标志的设备。 – Justin 2010-09-08 15:41:56

您正在使用该标志禁用文件系统缓存。是的，这与巨大的差异，它迫使操作系统与磁盘驱动程序一起工作并直接读取扇区。无法读取和缓存气瓶，禁用优化，使读取轨道无需移动读取头如此便宜。懒惰回写被禁用，这种优化使磁盘写入即时显示。

来源

2010-09-03 15:56:06

这是一个内存映射文件，不涉及硬盘访问。有 – Justin 2010-09-03 17:44:38

有。如果您为CreateFileMapping的hFile参数指定INVALID_HANDLE_VALUE，则它将由页面文件进行备份。检查它的SDK文档。 – 2010-09-03 17:48:07

这个改变为什么会把性能从32位写入64位。如果这是一个大问题，我会不会看到32bit的性能问题？ – Justin 2010-09-08 15:50:17

-1

我想，因为内存必须从64位重新映射到32位，提供一个“反弹”缓冲区变得非常昂贵。启用缓存时，此反弹缓冲区是隐含的，OS可能会绕过连续更新内存区段的需要。

来源

2010-09-03 15:54:49 Christopher

这就是我所倾向的，但1000毫秒这些操作似乎是过高的时间量。 – Justin 2010-09-03 17:51:09

跳动缓冲区只需要DMA硬件，它需要一个32位*物理*地址。在用户模式下的32位应用程序中，由MMU完成翻译，并且内存中的任何地址（甚至超过4GB）都可映射到32位虚拟地址。 – 2010-09-03 22:26:09

@ben：即使没有反弹缓冲区，从64位到32位的映射能否增加这种开销？ – Justin 2010-09-04 06:15:40

这里是Microsoft不得不说的那面旗帜：

的SEC_NOCACHE标志用于需要各种锁定结构位于内存不是永远取到的CPU缓存架构。在x86和MIPS 机器上，使用此标志只会减慢性能，因为硬件会使缓存保持一致。

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

来源

2010-09-03 16:10:03

这是真的，但是在32位这个减速小于10ms。在64内，它在1000毫秒的范围内。 – Justin 2010-09-03 17:47:48

@Justin：都是32bit的进程吗？至少在* NIX上，与由32位进程创建的共享内存相似的情况是从64位进程访问的，反之亦然。如果引用的文章有任何背后的真相，那么扔掉标志：Windows现在运行的所有多CPU /核心系统都显式缓存一致（不像第一个SMP系统十年前+ WinNT 3.5运行）。 – Dummy00001 2010-09-03 22:53:04

@Dummy：两个进程都是32位。感谢多核心点，我会研究这一点。我们使用的硬件只有一块需要这个标志，它在32位系统上使用。目前我们检查os是32还是64，并设置标志。我只是对这种放缓的根源感到好奇。 – Justin 2010-09-04 06:14:19

移动到64位操作系统时的共享内存性能降低

回答

相关问题