Messages in this thread | | | Date | Fri, 10 Feb 2006 14:36:36 +1100 | From | Nick Piggin <> | Subject | Re: msync() behaviour broken for MS_ASYNC, revert patch? |
| |
Andrew Morton wrote: > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >>Andrew Morton wrote: >> >>> >>>Well, for example you might want to msync a number of disjoint parts of the >>>mapping, then write them all out in one hit. >>> >> >>That should still be pretty efficient with 2.4 like behaviour? > > > It's a bit of a disaster if you happen to msync(MS_ASYNC) the same page at > any sort of frequency - we have to wait for the previous I/O to complete > before new I/O can be started. That was the main problem which caused this > change to be made. You can see that it'd make 100x or 1000x speed improvements > with some sane access patterns. >
I'm not sure you'd have to do that, would you? Just move the dirty bit from the pte and skip the page if it is found locked or writeback.
> >>pdflush >>does write them out in file offset order doesn't it? > > > pdflush does, but an msync(MS_ASYNC) which starts I/O puts the IO order > into the application's control. >
I don't see a problem with that. There are plenty of ways to shoot oneself in the foot.
> >>>Or you may not actually _want_ to start the I/O now - you just want pdflush >>>to write things back in a reasonable time period, so you don't have unsynced >>>data floating about in memory for eight hours. That's a quite reasonable >>>application of msync(MS_ASYNC). >>> >> >>I think data integrity requirements should be handled by MS_SYNC. > > > Well that's always been the case. MS_ASYNC doesn't write metadata. > >
So I don't understand your argument for using MS_ASYNC in that case.
-- 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/
| |