mmap semantics clarification

mmap semantics clarification

Post by Wesley W. Garlan » Sun, 27 Feb 2000 04:00:00

Hi, Group.

I'd like some external validation w.r.t. my take on the various mmap man
pages and Stevens books I have read lately, which seems to be correct
based on my current code body's behaviour.

(FYI, platforms of interest are Solaris 2.5.1+ (sparc), Solaris 7+
(x86), Linux kernel 2.0+)

1. If I open w/ MAP_SHARED and make changes to the mmap region, a write
to disk will be done some time before or during   munmap(). If I want
the read/write to be atomic against other instances of the application,
I should wrap any code wanting to change said memory area somehow (e.g.
with fcntl advisory locks).

2. If I open w/ MAP_PRIVATE changes will not be reflected on disk.

3. If I open w/ MAP_PRIVATE | MAP_NORESERVE and never change memory, I
do not cause the kernel to waste resources  expecting to make a spare
copy of my mmap()ed pages in a hurry.

4. If two applications load the same file MAP_PRIVATE and make no
changes to the mmap()ed area, then the kernel will share the same
physical pages of memory between them (assuming they are paged in :-).

Comments? I'm not really using mmap as a method providing shared memory
or a malloc replacement, just a nice way to get fast I/O off of the
disk. I replaced the stdio streams functions in one of my applications
with a read-only subset of those functions I wrote using mmap, and it
significantly sped up my top-down parsing/token-emission application
when the token emission stage was set to a nop(). I suspect this is
primarily because I was fetching data one line at a time with fgets()
and then processing it (which made for very easy-to-read/maintain code,
but not very efficient w.r.t. io buffers). I haven't worked on
optimizing the writes yet, as they are comparatively tiny  (usually
100-1000 times smaller than input).

I just really want to make sure I understand all of the relevant
semantics for this slightly obfuscated memory interface.

Final question: If two applications mmap the same file as MAP_SHARED,
make changes, and munmap, what controls what goes on the disk? Whoever
wrote last? /dev/random?

Final question II: What controls whether or not mmap can fail with



mmap semantics clarification

Post by Wesley W. Garlan » Mon, 28 Feb 2000 04:00:00

Hi, Casper;

Quote:>A write to disk will not necessarily be done before or during munmap().
>When you write to the page it gets dirty; it can then take a few
>before it gets written to disk.

>On systems with a unified filecache, the changes will be visible to
>all applications at once.

And, presumably, this is never the case for two machines across NFSv3,

Quote:>When you make changes, the cache coherency of the system is also
>important.  E.g., when you are writing instructions, those will
>end up in the D-cache; you will need to flush the processor's I-cache
>before it can use them.

Hmm - very interesting. So if I am mmap()ing a file to manipulate, and
out that I need to make some changes to it (usually in the first 100
bytes of
a 50-100k file in this case) that _must_ be world-visible by the time I
my lock, then I should simply MAP_PRIVATE and fwrite() my changes out?

Quote:>>Final question: If two applications mmap the same file as MAP_SHARED,
>>make changes, and munmap, what controls what goes on the disk? Whoever
>>wrote last? /dev/random?

>Whoever wrote last; note that the changes will be at the byte level
>not at the page level.  I.e., as long as the two applications write
>different addresses in the same page, the changes will  be merged.

Hey, that's neat. I never expected that.

Thank you very much for the feedback!