Messages in this thread | | | Date | Fri, 10 Feb 2006 17:31:02 +1100 | From | Nick Piggin <> | Subject | Re: msync() behaviour broken for MS_ASYNC, revert patch? |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>and had no need for a MS_SYNC anywhere in the meantime. >>If you did have the need for MS_SYNC, then kicking off the IO >>ASAP is going to be more efficient. > > > Of course these sorts of applications don't know what they'll be doing in > the future. Often the location of the next update is driven by something > which came across the network. >
If there is no actual need for the application to start a write (eg for data integrity) then why would it ever do that?
> > There's no need to do that. Look: > > msync(MS_ASYNC): propagate pte dirty flags into pagecache > > LINUX_FADV_ASYNC_WRITE: start writeback on all pages in region which are > dirty and which aren't presently under writeback. > > LINUX_FADV_WRITE_WAIT: wait on writeback of all pages in range. > > I think that covers all conceivable scenarios. One thing per operation, > leave the decisions and tuning up to the application. And it gives us two > operations which are also useful in association with regular write(). >
Oh yeah it is easy if you want to define some more APIs and do it in a Linux specific way.
But the main function of msync(MS_ASYNC) AFAIK is to *start* IO. Why do we care so much if some application goes stupid with it? Why not introduce a linux specific MS_flag to propogate pte dirty bits?
-- 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/
| |