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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux