msync() differences between Linux and FreeBSD
marcus at blazingdot.com
Wed Jul 2 12:00:03 UTC 2008
I recently had a patch accepted to the ports collection that took out an msync()
call that seriously detrimented performance for rrdtool updates. It seems that
in FreeBSD, msync() waits for bits to be committed to disk even when MS_ASYNC
is specified. Under Linux, there is not such a wait for msync().
First off, I don't know how frequently msync() is used, and whether changing
its behavior would impact the performance of many things.
It's possible that FreeBSD msync() behavior is more correct in some ways. From
a message from Matt Dillon on this same list:
It used to be that msync() only synced VM pages to the underlying
file, making them consistent with read()'s and write()'s against
the underlying file. Since FreeBSD uses a unified VM page cache
this is always true. However, the Open Group specification now
requires that the dirty pages actually be written out to the underlying
media... i.e. issue real I/O. So msync() can't be a NOP if you go by
the OpenGroup specification.
Is there a spec that FreeBSD is adhering to that prevents msync() with
MS_ASYNC from being a NOP, seeing as munmap() does the job? And does this
really matter for the real-world performance of some apps?
More information about the freebsd-stable