On Mon, Aug 31, 2015 at 11:56:12AM -0700, Christoph Hellwig wrote: > On Mon, Aug 31, 2015 at 02:02:22PM -0400, Brian Foster wrote: > > Ok, but the comment for blk_start_plug() mentions some kind of flush on > > task sleep mechanism. I could be wrong, but I take this to mean there > > are cases where I/O can initiate before the plug is stopped. Does > > deferring the I/O submission across writepages defeat that heuristic in > > any way? My (preliminary) understanding is that while the I/O submission > > would still be deferred by the plug in the same way in most cases, we're > > potentially holding back I/Os from the block infrastructure until the > > entire writepages sequence is complete. > > Yes, we do. But the reason why the block layer needs to flush the > plug on context switch is because we only have a limited bio mempool, > and if processes that are not running consume that we can't make > guaranteed progress. The XFS writeback code doesn't allocate bios > until the end we are not affected by that particular issues, although > we still need to worry about our own ioend mempools. The patch changes the bio allocation patterns - it allocates them on the fly and holds them, so we could potentially exhaust the bio mempool with this submission technique. The ioend allocation pattern is different, too, because we only used to have 1 per buffer on a writepage call and the last one was used for the write clustering. > Sidenote: Jens now has the arbitrarily sized bio code in his queue > for 4.3. With that we could replace our ioends with bios that have > a little private data and simplify the submission phase of the > writeback code significantly. Yes, I've been keeping an eye on that and waiting for it to land as it solves many of the above problems. I still wanted to get the write cluster infrastructure changes underway, though, so I can work on making the writeback path not use bufferheads at all... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
