On Tue 03-08-10 12:36:10, Christoph Hellwig wrote: > The patch looks correct to me, but I wonder if we shouldn't try to > get rid of writeback_in_progress instead. There's just two users, Interesting. Yes, it might make sense. > one is the ext4 writeback_if_idle hack, and the other one is > balance_dirty_pages. The latter really should only care about about > other background reclaim beeing pending, and I have no idea why the > former cares - if e.g. any kind of kupdate in the background is pending > which just writes out a few inodes on another fs on the same bdi > it's exiting. The XFS variant of this does unconditional writeback > for all inodes on the sb. You are right that writeback_if_idle probably isn't the right thing ext4 needs. You are also right about the call in balance_dirty_pages but that's harder to solve (as we definitely do not want to file a work item in each balance_dirty_pages call). > 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. 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
