Messages in this thread | | | Date | Sat, 11 Feb 2006 05:38:19 +1100 | From | Nick Piggin <> | Subject | Re: 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/
| |