Talk:Memory-mapped file

I dont get it

ok

Is there _I/O_ performance benefit of mmaped files?

The pages gives the impression that it is faster to access mmaped files compared to I/O syscalls. However, the it is a faulty conclusion as it's based on comparison of memory access to actual I/O. There is no I/O involved in accessing a cached memory page of mmapped file. The same "benefit" may be achieved by using locally-buffered "I/O" e.g. like fwrite() does. —Preceding unsigned comment added by 129.97.169.227 (talk) 20:07, 23 March 2011 (UTC)[reply]

Drawbacks: Page faults in mmapping vs. in syscalls

The sentence "The memory mapped approach has its cost in page faults - when a piece of data isn't actually loaded by the operating system" is unlikely - both ways have a chance to request data not in the cache. Yes, when doing random reads the memory-mapped access is usually chosen (because no need to call seek()), but such access is slow because of the random reads, not because of memory-mapping. Also OS provides both fadvise() (for syscall access) and madvise() (for mmapping). Therefore the cache-miss probability is the same.

I propose to delete the paragraph. --Alvin-cs ✉ 13:25, 11 September 2009 (UTC)[reply]

The explanation given in the article indeed doesn't seem to make a lot of sense, but it's certainly true that mmap is not always faster than read. Even when accessing a cached mmap'ed file, the process would still be generating minor page faults — for pages that do exist in the page cache, but are not yet mapped into the process's VM space. Creating these mappings involves among other things modifying page tables and invalidating the CPU's TLB (translation lookaside buffer, basically the CPU's MMU cache for VM mappings). These operations come at a cost that can exceed the cost of buffer copies. In small microbenchmarks you usually don't feel the overhead, but larger apps take a bigger hit because they rely more on the TLB.

I didn't spend much time looking for references, but here's one that explains the gist of it: [1] -- intgr [talk] 18:32, 11 September 2009 (UTC)[reply]

Minor page faults, a good one, Sir. If the TLB does not cache missing mappings (likely, since they are either fatal or result in re-mapping) then it does not require invalidation. But it looks like syscall-style penalty anyway. -- Updated the article. Removed the not-even-in-cached case.--Alvin-cs ✉ 00:46, 13 September 2009 (UTC)[reply]

History

There should be a history section. What is the first system with memory mapped files? 4.1cBSD? 91.154.87.201 (talk) 15:34, 23 March 2012 (UTC)[reply]