迁移到 64 位操作系统时共享内存性能降低
我在 64 位 Windows 上运行 32 位旧版应用程序时遇到问题。相关应用程序使用 CreateFileMapping 创建共享内存。当它在 64 位 Windows 上运行时，从另一个进程访问此共享内存的任何尝试都需要大约 1 秒。共享内存是使用页面保护标志创建的：
flProtect = PAGE_READONLY | SEC_NOCACHE | SEC_COMMIT;
当使用以下内容创建相同的内存时：
flProtect = PAGE_READONLY | SEC_COMMIT;
问题消失。目前，这种解决方法是可以接受的，但我们确实有一些设备需要设置 SEC_NOCACHE 标志。
有人可以告诉我为什么 SEC_NOCACHE 在这种情况下会影响性能吗？
更新：似乎仅写入此缓冲区的时间就增加到了 1000ms。阅读似乎没有受到影响。这次我们向缓冲区写入了大约 5MB 的数据。
Update2：该软件在许多系统上使用，其中一个系统具有需要使用该标志的物理设备。我们目前仅限于在 32 位 Windows 中运行带有此设备的机器。
I am having an issue with a 32-bit legacy app running on 64-bit windows. The app in question uses CreateFileMapping to create shared memory. When this is run on 64-bit Windows any attempt to access this shared memory from another process takes about 1 second. The shared memory is created using page protection flags:
flProtect = PAGE_READONLY | SEC_NOCACHE | SEC_COMMIT;
when the same memory is created using:
flProtect = PAGE_READONLY | SEC_COMMIT;
the issue disappears. For now this work around is acceptable, but we do have some devices that require the SEC_NOCACHE flag to be set.
Can someone enlighten me on why SEC_NOCACHE would affect performance in this situation?
Update: it seems that only writing to this buffer has increased to 1000ms. Reading does not seem to be affected. We are writing about 5MB to the buffer in this time.
Update2: This software is used on many systems, and one of the systems has a physical device that requires the use of this flags. We are currently limited to running the machine with this device in 32bit windows.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以下是 Microsoft 关于该标志的说法：
不幸的是，他们没有量化减速的程度。
Here's what Microsoft has to say about that flag:
Unfortunately they don't quantify the amount of slow down.
您正在使用该标志禁用文件系统缓存。是的，这会产生巨大的差异，它迫使操作系统与磁盘驱动程序一起工作并直接读取扇区。柱面无法读取和缓存，从而禁用了无需移动读取头即可读取磁道的优化。并且禁用了延迟写回，这是一种使磁盘写入看起来是瞬时的优化。
You are disabling the file system cache with that flag. Yes, that makes an enormous difference, it forces the OS to work with the disk driver and read sectors directly. Cylinders cannot be read and cached, disabling the optimization that makes reading tracks without having to move the read head so cheap. And lazy write-back is disabled, an optimization that makes disk writes appear instantaneous.
我猜想，因为内存必须从 64 位重新映射到 32 位，所以提供“反弹”缓冲区会变得昂贵。当启用缓存时，该反弹缓冲区是隐式的，操作系统可以避免不断更新内存部分的需要。
I would guess, that because the memory has to be remapped from 64-bit to 32-bit, it becomes expensive to provide a 'bounce' buffer. When caching is enabled, this bounce buffer is implicit and the OS may circumvent the need to continously update the memory section.