On Tue, Aug 03, 2010 at 10:55:34PM +0200, Jan Kara wrote: > > Long term I wonder if we shouldn't get rid of the work list entirely, > > and just have a few targets for the flusher thread - we just set a > > target and wake it up, and it keeps running until all targets are met. > I cannot quite see how that would work when several threads want to > meet different targets. But I can imagine that background writeback > (and kupdate style which I belive should be basically wrapped into the > background) wouldn't have a work item in a list but whenever the flusher > thread has nothing else to do, it just writes things out until there are no > old inodes and we are below dirty_background_ratio. The targets would be per-bdi_writeback and we have exactly one thread for each of those. If we'll eventually need more than one thread per filesystem we'll need to add multiple bdi_writeback structure. E.g. for XFS we could align them easily to allocation group boundaries. Anyway, for kupdate we do in fact already have this target with the older than this marker, and Wu's patches make it even more seamlessly integrated. For the background style writeback we already have the over_bground_thresh in wb_writeback, so with a little restructuring we can totally get rid of a work item for thes, too and just wake up the flusher thread. As you mention in the last mail the laptop mode flush everthing code is just a special case of background writeout with a dirty limit of zero, we could also converted that to a target instead of submitting a work item. The only special cases in this model are the per-sb calls. -- 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
