lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: msync() behaviour broken for MS_ASYNC, revert patch?
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/

\
 
 \ /
  Last update: 2006-02-10 19:41    [W:0.069 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site