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

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

Linus Torvalds wrote:
> On Sat, 11 Feb 2006, Nick Piggin wrote:
>
> > It seems very obvious to me that it is a hint. If you wer expecting
> > to call msync(MS_SYNC) at some point, then you could hope that hinting
> > with msync(MS_ASYNC) at some point earlier might improve its efficiency.
>
>
> And it will. MS_ASYNC tells the system about dirty pages. It _should_ 
> actually initiate writeback if the system decides that it has lots of 
> dirty pages. Of course, if the system doesn't have a lot of dirty pages, 
> the kernel will decide that no writeback is necessary.
>
> If you (as an application) know that you will wait for the IO later (which 
> is _not_ what MS_ASYNC talks about), why don't you just start it?

It depends how you interpret the standards and what you think sensible
behaviour would be, I guess (obviously our current MS_ASYNC is not
technically buggy, we're arguing about whether or not it is suboptimal).

But given that there is an MS_INVALIDATE (I interpret mmap + MS_INVALIDATE
should work as write()), and that one would _expect_ MS_ASYNC to closely
match MS_SYNC, I think MS_ASYNC should start writeout straight away.

The fact that we've historically had a buggy MS_INVALIDATE implementation
is a non argument when it comes to the interpretation of the standards.

> ie what's wrong with Andrew's patch which is what I also encourage?
>
> I contend that "mmap + MS_ASYNC" should work as "write()". That's just 
> _sensible_.
>
> Btw, you can equally well make the argument that "write()" is a hint that 
> we should start IO, so that if we do fdatasync() later, it will finish 
> more quickly. It's _true_. It just isn't the whole truth. It makes things 
> _slowe_ if you don't do fdatasync(), the same way you can do MS_ASYNC 
> without doing MS_SYNC afterwards.

I wouldn't argue that because I don't agree with your contention. I
argue that MS_ASYNC should do as much of the work of MS_SYNC as possible,
without blocking.

From the standard (msync):

  Description
    The msync() function shall write all modified data to permanent storage
    locations...

    When MS_ASYNC is specified, msync() shall return immediately once all
    the write operations are initiated or queued for servicing;

It is talking about write operations, not dirtying. Actually the only
difference with MS_SYNC is that it waits for said write operations (of the
type queued up by MS_ASYNC) to complete.

So our current MS_ASYNC behaviour might technically not violate a standard
(depending on what you consider initiating / queueing writes), but it would
be akin to having MS_SYNC waiting for pages to become clean without actually
starting the writeout either (which is likewise inefficient but technically
correct).

[snip smooth writeback]

That would be a nice thing yes, but again I don't agree that MS_ASYNC
is semantically equivalent to write()

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