Re: msync() needed before munmap() when writing to shared mapping?

From: Andrew Morton
Date: Fri Apr 16 2004 - 18:59:41 EST

Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:
> ...
> A related question. The comment for MADV_DONTNEED says:
> * NB: This interface discards data rather than pushes it out to swap,
> * as some implementations do. This has performance implications for
> * applications like large transactional databases which want to discard
> * pages in anonymous maps after committing to backing store the data
> * that was kept in them. There is no reason to write this data out to
> * the swap area if the application is discarding it.
> *
> * An interface that causes the system to free clean pages and flush
> * dirty pages is already available as msync(MS_INVALIDATE).
> MADV_DONTNEED calls zap_page_range().
> That propagates dirtiness into the pagecache.
> So it *doesn't* "discard data rather than push it out to swap", if the
> same dirty data is mapped elsewhere e.g. as a shared anonymous
> mapping, does it?

Sure. If some other process is using the same pages we don't go toss them

> The comment also mentions MS_INVALIDATE, but MS_INVALIDATE doesn't do
> what the comment says and doesn't implement anything like POSIX
> either. (Linux's MS_INVALIDATE is practically equivalent to MS_ASYNC).

Seems that way - MS_INVALIDATE will simply propagate pte dirtiness into
page dirtiness. For non-file-backed mappings it is a no-op.

> Is there a call which does what the command about MS_INVALIDATE says,
> i.e. free clean pages and flush dirty ones?

Not really. What is a clean anonymous page? If it's ever been written to,
it's conceptually dirty, whether or not it is physically dirty. ie: if you
invalidate it, you've lost your data.

I guess you could get a similar result by munmap() and then mmapping it

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at