On Sun, 2007-04-22 at 00:19 -0700, Andrew Morton wrote: > It could be that we never call test_clear_page_writeback() against > !bdi_cap_writeback_dirty() pages anwyay. I can't think why we would, but > the relationships there aren't very clear. Does "don't account for dirty > memory" imply "doesn't ever do writeback"? One would need to check, and > it's perhaps a bit fragile.
I did, thats how that test ended up there; I guess a comment would have been a good thing, no? :-) end_swap_bio_write() calls end_page_writeback(), and swap_backing_dev_info has neither cap_writeback nor cap_account_dirty. > It's worth checking though. Boy we're doing a lot of stuff in there > nowadays. > > OT: it might be worth looking into batching this work up - the predominant > caller should be mpage_end_io_write(), and he has a whole bunch of pages > which are usually all from the same file, all contiguous. It's pretty > inefficient to be handling that data one-page-at-a-time, and some > significant speedups may be available. Right, that might be a good spot to hook into, I'll have a look. > Instead, everyone seems to think that variable pagecache page size is the > only way of improving things. Shudder. hehe, I guess you haven't looked at my concurrent pagecache patches yet either :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/