Bug 134954 - msync(start, size, MS_ASYNC) and msync(start, size, MS_SYNC) behave equal
Summary: msync(start, size, MS_ASYNC) and msync(start, size, MS_SYNC) behave equal
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: x86_64 Linux
medium
high
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-07 14:45 UTC by Arno Kröner
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-11 19:25:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Arno Kröner 2004-10-07 14:45:24 UTC
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.

Comment 2 Stephen Tweedie 2005-02-11 19:25:04 UTC
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.


Comment 3 Stephen Tweedie 2005-02-11 19:28:33 UTC
Incidentally, see also bug #117993 for a closely-related issue which is actually
complaining about earlier kernels *not* submitting IO on MS_ASYNC.



Note You need to log in before you can comment on or make changes to this bug.