Red Hat Bugzilla – Bug 134954
msync(start, size, MS_ASYNC) and msync(start, size, MS_SYNC) behave equal
Last modified: 2007-11-30 17:07:04 EST
OS: Redhat Advanced Server 3/Update2 with kernel 2.4.21-20.ELsmp
System: 4 Opteron CPUs with 32GB RAM
Our Developers wrote a short program to test
asynchron and synchron msync calls
The Result: the calls behave equal and return immediately
We expected: async msync call return immediately and synchron calls
after successfull sync.
With the plain Linux-Kernels we see not this behavior, so we think
this is some extension from redhat.
What are the details of the test program?
In upstream 2.4.21 kernels, MS_ASYNC would wait for existing IO to complete if
it found any IO in flight. The implication is that a single MS_ASYNC call will
be asynchronous --- it will submit background IO but not wait for it --- but a
subsequent call will be pseudo-synchronous, as it waits not for its own IO to
complete, but for the *previous* call's IO to complete.
So if you time MS_ASYNC in a loop, yes, you'll see it costing the same as MS_SYNC.
This was upstream behaviour. It has changed for 2.6 kernels, but RHEL3
inherited that upstream behaviour for 2.4.21 and it is too late to change it now.
As a Linux-specific workaround, calling msync() with flags == 0 (ie. no MS_SYNC
or MS_ASYNC at all) will have a fully async effect even on 2.4.21-era kernels.
Incidentally, see also bug #117993 for a closely-related issue which is actually
complaining about earlier kernels *not* submitting IO on MS_ASYNC.