Bad*_*ild 7 linux kernel mmap shared-memory linux-kernel
假设我想对可能非常大的文件执行顺序写入.
如果我在整个区域上mmap()一个巨大的区域和madvise(MADV_SEQUENTIAL),那么我可以以相对有效的方式写入内存.我已经开始工作了.
现在,为了在我编写时释放各种OS资源,我偶尔会在已经写入的小块内存上执行munmap().我担心的是munmap()和msync()会阻塞我的线程,等待数据物理地提交到磁盘.我根本无法放慢作家的速度,所以我需要找到另一种方式.
在已经写好的小块内存中使用madvise(MADV_DONTNEED)会更好吗？我想告诉操作系统懒惰地将内存写入磁盘,而不是阻止我的调用线程.
madvise()的联机帮助页有这样说,这是相当模糊的:
MADV_DONTNEED
Do not expect access in the near future. (For the time being, the
application is finished with the given range, so the kernel can free
resources associated with it.) Subsequent accesses of pages in this
range will succeed, but will result either in re-loading of the memory
contents from the underlying mapped file (see mmap(2)) or
zero-fill-on-demand pages for mappings without an underlying file.
Dam*_*mon 14
为了你自己的利益,远离MADV_DONTNEED.Linux 不会把它作为一个提示,在写完之后扔掉页面,而是立即将它们扔掉.这不是一个错误,而是一个深思熟虑的决定.
讽刺的是,理由是,非破坏性的功能MADV_DONTNEED已经被给予msync(MS_INVALIDATE|MS_ASYNC),MS_ASYNC而另一方面没有启动的I/O(事实上,它什么都没有,下面的理由是脏页写回正常工作反正),fsync总是阻塞,如果你超过一些模糊的限制sync_file_range 可能会阻止,并且文档认为这是非常危险的,无论这意味着什么.
无论哪种方式,您必须msync(MS_SYNC),或fsync(阻止),或sync_file_range(可能阻塞)后跟fsync,否则您将丢失数据MADV_DONTNEED.如果你不能阻止,你可能别无选择,但要在另一个线程中做到这一点.
首先， madv_sequential 启用积极的预读，因此您不需要它。其次，操作系统无论如何都会将脏文件烘焙内存写入磁盘，即使您什么也不做。但 madv_dontneed 会指示它立即释放内存（您称之为“各种操作系统资源”）。第三，尚不清楚用于顺序写入的映射文件有什么优势。你可能会通过 write(2) 得到更好的服务（但使用缓冲区 - 手动或 stdio）。