Bryan Henderson wrote: > Nick Piggin <npiggin@xxxxxxx> wrote on 01/20/2009 05:36:06 PM: > > > On Tue, Jan 20, 2009 at 01:25:59PM -0800, Bryan Henderson wrote: > > > > For this, taking a vector of multiple ranges would be nice. > > > > Alternatively, issuing parallel fsync_range calls from multiple > > > > threads would approximate the same thing - if (big if) they aren't > > > > serialised by the kernel. > > > > > > That sounds like a job for fadvise(). A new FADV_WILLSYNC says you're > > > > planning to sync that data soon. The kernel responds by scheduling > the > > > I/O immediately. fsync_range() takes a single range and in this case > is > > > just a wait. I think it would be easier for the user as well as more > > > flexible for the kernel than a multi-range fsync_range() or multiple > > > threads. > > > > A problem is that the kernel will not always be able to schedule the > > IO without blocking (various mutexes or block device queues full etc). > > I don't really see the problem with that. We're talking about a program > that is doing device-synchronous I/O. Blocking is a way of life. Plus, > the beauty of advice is that if it's hard occasionally, the kernel can > just ignore it. If you have 100 file regions, each one a few pages in size, and you do 100 fsync_range() calls, that results in potentally far from optimal I/O scheduling (e.g. all over the disk) *and* 100 low-level disk cache flushes (I/O barriers) instead of just one at the end. 100 head seeks and 100 cache flush ops can be very expensive. This is the point of taking a vector of ranges to flush - or some other way to "plug" the I/O and only wait for it after submitting it all. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
