Re: msync() behaviour broken for MS_ASYNC, revert patch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Andrew Morton wrote:

Nick Piggin <[email protected]> wrote:


I don't think anyone would use MS_ASYNC for anything other than
performance improvement, so it is not like we need super well
defined behaviour... the earlier it will start IO AFAIKS the better.



Well, no.  Consider a continuously-running application which modifies its
data store via MAP_SHARED+msync(MS_ASYNC).  If the msync() immediately
started I/O, the disk would be seeking all over the place all the time.  The
queue merging and timer-based unplugging would help here, but it won't be
as good as a big, infrequent ascending-file-offset pdflush pass.



Sure you can shoot yourself in the foot.

  "msync  flushes  changes  made  to  the  in-core copy of a file that
   was mapped into memory using mmap(2) back to disk. "

We usually don't cater to foot shooters at the expense of valid users.

AFAIKS, basically the only valid use for MS_ASYNC is for the app to tell
the kernel that it isn't going to write here for a long time, so writeback
may as well be scheduled; or to pipeline other work with an upcoming data
integrity point which will need to be guaranteed by a second call to MS_SYNC.


Secondly, consider the behaviour of the above application if it is modifying
the same page relatively frequently (quite likely).  If MS_ASYNC starts I/O
immediately, that page will get written 10, 100 or 1000 times per second. If MS_ASYNC leaves it to pdflush, that page gets written once per 30 
seconds, so we do far much less I/O.

We just don't know.  It's better to leave it up to the application designer
rather than lumping too many operations into the one syscall.


Well it remains the same conceptual operation (asynchronously "schedule"
dirty pages for writeout). However it simply becomes more useful to start
the writeout immediately, given that's the (pretty explicit) hint that is
given to us.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com - 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux