sync() 调用和 sync 命令有何不同？

Question

我使用 mmap() 和 fopen("/dev/mem") 来创建一个映射到 ARM 系统中两个处理器内核之间共享的物理内存块。当运行 Linux 的处理器写入内存时，在其他非 Linux 处理器看到写入的数据之前可能会有超过一秒的延迟。如果 Linux 进程在写入内存后立即进行此系统调用，那么长时间的延迟就会消失：

system("sync; echo 3 > /proc/sys/vm/drop_caches" );

我尝试直接在代码中复制该逻辑，但长时间的延迟仍然存在：

int fd;
char* data = "3";
sync();
fd = open("/proc/sys/vm/drop_caches", O_WRONLY);
write(fd, data, sizeof(char));
close(fd);

为什么 sync() 调用与同步系统命令的行为不同？同步命令是否会影响同步（）调用不影响的虚拟内存刷新？

我知道手册说同步程序除了执行 sync(2) 系统调用之外什么都不做，但是我从用户空间调用 sync() 的事实会影响它的行为吗？它的作用就像从用户空间调用同步只是安排同步而不是阻塞直到完成。

Answer 1

你忘记换行了。

echo 3 输出"3\n"。

此外，您正在采取一种非常迂回的方式来实现共享内存，并且这样做会给操作系统的其余部分带来巨大的成本。

每次调用 sync-the-command 或 sync-the-system-call 时，都会导致操作系统刷新整个计算机上的每个文件系统；更糟糕的是，您告诉操作系统忘记它拥有的每个文件系统缓冲区，从而迫使操作系统从磁盘重新读取所有内容。几乎所有你能想到的方式都对整个操作系统的性能造成了恶劣的影响。

有一个更简单的方法。

使用 shm_open() 创建一个命名的共享内存区域。使用 mmap 访问它。 仅在该内存块上使用内存屏障或共享/命名互斥体，以确保您可以一致且安全地对其进行读写。

就复杂性而言，您当前的方法可能比普通共享内存的成本高出 1,000,000 倍。

Answer 2

drop_caches 和 sync 在这里都不合适，因为它们都处理文件系统缓存——这实际上并不是您在这里遇到的。 sync 似乎解决了它的事实可能是巧合。 （可能是在启动sync 工具时顺便刷新了数据缓存。）

您的应用程序很可能在系统上的两个处理器内核之间遇到缓存同步问题。尝试使用cacheflush() 系统调用来解决这个问题：

#include <unistd.h>
#include <asm/unistd.h>
...
syscall(__ARM_NR_cacheflush, mapping_ptr, mapping_ptr + mapping_length, 0);

请注意，您可能需要在两个进程中刷新缓存才能看到正确的结果。

其他映射设备通常需要刷新对映射内存的更改，但我认为在这种情况下可能不需要。不过，尝试msync() 也无妨：

msync(mapping_ptr, mapping_length, MS_SYNC); // on process writing to memory
msync(mapping_ptr, mapping_length, MS_INVALIDATE); // on process reading from memory

最后，确保您使用MAP_SHARED 标志映射此内存。