On Tue 03-08-10 12:33:21, Christoph Hellwig wrote: > On Tue, Aug 03, 2010 at 06:20:38PM +0200, Jan Kara wrote: > > Background writeback and kupdate-style writeback are easily livelockable > > (from a definition of their target). This is inconvenient because it can > > make sync(1) stall forever waiting on its queued work to be finished. > > Fix the problem by interrupting background and kupdate writeback if there > > is some other work to do. We can return to them after completing all the > > queued work. > > I don't think this is quite correct. If the only other callers was > fsync_filesystems that would be true, but we also have the odd > writeback_if_idle hack in ext4, and the bdi_start_writeback hack > in laptop mode. Yes, I'm aware of these. But do they really matter? bdi_start_writeback() hack is almost like background writeback (it's write-it-all thing) and so yielding to it does not change much. Similarly the writeback_if_idle thing (although that works only for a single sb which makes difference if there are several active filesystems on the bdi). But regardless of what other work items actually do, I view background / kupdate writeback as the type of thing we do when noone else sends bdi dirty data to the backing device. So if someone has actually idea what to write out, we give it priority and then return to doing our background / kupdate writeback. What do you think? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
