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:
>
> > > 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.
>
>
> That would make MS_ASYNC mean "start I/O now, unless there's I/O in
> progress, in whch case start I/O in 30 seconds.  That's not good.

Yes, that change would make MS_ASYNC asynchronously start as much
IO as possible, as soon as possible. Which is good for the problem
reporter, who uses it to pipeline IOs and seems to have fairly good
control of when IO starts and finishes.

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.

> If we're going to change the kernel, better off using fadvise()
> enhancements, whic are also useful for post-write() operations.

I don't think there is any downside to changing MS_ASYNC either,
though.

--
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/