On Thu, Mar 08, 2012 at 03:42:52PM -0500, Jeff Moyer wrote: > Chris Mason <chris.mason@xxxxxxxxxx> writes: > > > On Thu, Mar 08, 2012 at 12:20:26PM -0800, Boaz Harrosh wrote: > >> I think I understand this one. It's do to the sync nature introduced > >> by page_waiting in mkwrite. > > > > Pages go from dirty to writeback for a few reasons. Background > > writeout, or O_DIRECT or someone running sync > > > > background writeout shouldn't be queueing up so much work that > > synchronous writeout has a 2 second delay. > > So now we're back to figuring out how to tell how long I/O will take? > If writeback is issuing random access I/Os to spinning media, you can > bet it might be a while. Today, you could lower nr_requests to some > obscenely small number to improve worst-case latency. I thought there > was some talk about improving the intelligence of writeback in this > regard, but it's a tough problem, especially given that writeback isn't > the only cook in the kitchen. I'm not against Ted's original idea, but I'd hate to miss the chance to blame Jens for the block layer making filesystems slow. Since there is a reliable way to reproduce, it makes sense to track it down a little more instead of papering over the wait_on_page_writeback call. -chris -- 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
