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

[Nick Piggin]

Andrew Morton wrote:
> Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/