On Mon, Aug 01, 2011 at 01:52:12PM +0800, Wu Fengguang wrote: > There is another type of work that won't abort: the one that started > by __bdi_start_writeback() and I'd call it "nr_pages" work since its > termination condition is simply nr_pages and nothing more. It's not > the for_background or for_kupdate works that will abort as soon as > other works are queued. We have two callers of __bdi_start_writeback: bdi_start_writeback and wakeup_flusher_threads. The first one want to write all pages for a bdi when a laptop-mode completion comes in. It's a bit like the first pass of a sync in that it's a) asynchronous and b) skipping inodes or even superblocks has absolutely no data integrity or system balance effect. The second one is a huge mess. We may call it either in places like sync that want to write all pages, and have similar characteristics as above. Or in some places where the VM wants to write a certain number of pages - but the writeback code totally fucks that goal up by trying to write the requested number of pages per BDI, leading to much more massive writeback than we have requested on any larger system. And what the callers appear to actually want is to either increase background writeback a bit, or free a certain number of pages (in one case even just in the lowmem zone). -- 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
