On Thu, Mar 08, 2012 at 04:24:12PM -0500, Ted Ts'o wrote: > On Thu, Mar 08, 2012 at 12:20:26PM -0800, Boaz Harrosh wrote: > > > > I have a theory of how we can fix that 2-sec wait, by avoiding writeback of > > the last n pages of an inode who's mtime is less then 2-sec. This would > > solve any sequential writer wait penalty, which is Ted's case > > That won't work in general, *unless* 2 seconds is enough time that the > appending writer is done writing to that particular 4k page and moved > on to the next 4k block, so nothing touches that page and potentially > blocks for however long it takes for the queues to drain. > > Let's take another example, suppose you have a file-backed mmap > region, and you modify the page, and now let's suppose the process is > under enough memory pressure that the page cleaner decides to initiate > writeback of the page. Now suppose you get unlucky (this is the 1% or > 0.1% case; remember, 99th or 99.9 percentile latencies matter), and > you try to modify the page in question again. ***THUNK*** your > process takes a page fault, and is frozen solid in amber for > potentially seconds until the I/O queues drain. > > Hmm.... let's turn this around. If the issue is checksum calculation, > how about trying to solve this problem in some cases by deferring the > checksum calculation until right before the block I/O layer is going > to schedule the write (i.e., have the I/O submitter provide a callback > function which calculates the checksum, which gets called by the BIO > layer at the very last moment)? Btrfs currently does this, and the DIF code is by definition right before the write. The pages really only get set writeback when they are being sent in flight, so the waiting being done by the stable pages patch is file_write or page_mkwrite being polite and waiting for the IO to finish before changing the page. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
