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

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>>Andrew Morton wrote:
>>
>>>
>>>Well, for example you might want to msync a number of disjoint parts of the
>>>mapping, then write them all out in one hit.
>>>
>>
>>That should still be pretty efficient with 2.4 like behaviour?
> 
> 
> It's a bit of a disaster if you happen to msync(MS_ASYNC) the same page at
> any sort of frequency - we have to wait for the previous I/O to complete
> before new I/O can be started.  That was the main problem which caused this
> change to be made.  You can see that it'd make 100x or 1000x speed improvements
> with some sane access patterns.
> 

I'm not sure you'd have to do that, would you? Just move the dirty bit
from the pte and skip the page if it is found locked or writeback.

> 
>>pdflush
>>does write them out in file offset order doesn't it?
> 
> 
> pdflush does, but an msync(MS_ASYNC) which starts I/O puts the IO order
> into the application's control.
> 

I don't see a problem with that. There are plenty of ways to shoot oneself
in the foot.

> 
>>>Or you may not actually _want_ to start the I/O now - you just want pdflush
>>>to write things back in a reasonable time period, so you don't have unsynced
>>>data floating about in memory for eight hours.  That's a quite reasonable
>>>application of msync(MS_ASYNC).
>>>
>>
>>I think data integrity requirements should be handled by MS_SYNC.
> 
> 
> Well that's always been the case.  MS_ASYNC doesn't write metadata.
> 
> 

So I don't understand your argument for using MS_ASYNC in that case.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com