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:



If there is no actual need for the application to start a write (eg
for data integrity) then why would it ever do that?



To get the data sent to disk in a reasonable amount of time - don't leave it
floating about in memory for hours or days.



This is a Linux implementation detail. As such it would make sense to
introduce a new Linux specific MS_ flag for this.


Oh yeah it is easy if you want to define some more APIs and do
it in a Linux specific way.

But the main function of msync(MS_ASYNC) AFAIK is to *start* IO.
Why do we care so much if some application goes stupid with it?



Because delaying the writeback to permit combining is a good optimisation.



Definitely. And when the app gives us a hint that it really wants the
data on the disk, starting it as early as possible is also a good
optimisation.





Why not introduce a linux specific MS_flag to propogate pte dirty
bits?



That's what MS_ASYNC already does.  We're agreed that something needs to
change and we're just discussing what that is.  I'm proposing something
which is complete and flexible.



I don't think there's anything wrong with your fadvise additions.
I'd rather see MS_ASYNC start IO immediately and add another MS_
flag for Linux to propogate bits.

MS_ASYNC behaviour would also somewhat match your proposed FADV_ASYNC
behaviour.




Another point here is that msync(MS_SYNC) starts writeout of _all_ dirty
pages in the file (as MS_ASYNC used to do) and it waits upon writeback of
the whole file.  That's quite inefficient for an app which has lots of
threads writing to and msync()ing the same MAP_SHARED file.

We could easily enough convert msync() to only operate on the affected
region of the (non-linearly-mapped) file.  But I don't think we can do that
now, because people might be relying upon the side-effects.



I think if the interface was always documented correctly then we should
be able to. If the app breaks it was buggy anyway.


The fadvise() extensions allow us to fix this.  And we've needed them for
some time for regular write()s anyway. 

Yes they'd be nice.

Instead of
LINUX_FADV_ASYNC_WRITE
LINUX_FADV_WRITE_WAIT

can we have something more consistent? Perhaps
FADV_WRITE_ASYNC
FADV_WRITE_SYNC

--
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