On Wed, Oct 07, 2009 at 07:37:35PM +0800, Nikita Danilov wrote: > 2009/10/7 Wu Fengguang <fengguang.wu@xxxxxxxxx>: > > On Wed, Oct 07, 2009 at 06:38:37PM +0800, Nikita Danilov wrote: > >> Hello, > >> > > [...] > > > > > Glad to know about your experiences :) Interestingly I started with > > ->writepage() and then switch to ->writepages() because filesystems > > behave better with the latter (i.e. less file fragmentation). > > By the way, why is your patch doing > > ->writepage(page->index); > generic_writepages(page->index + 1, LUMPY_PAGEOUT_PAGES - 1); > > instead of > > generic_writepages(page->index, LUMPY_PAGEOUT_PAGES); > > ? Is this because of the difficulties with passing back page specific > errors from generic_writepages()? Yes. It's possible to tell write_cache_pages() to return AOP_WRITEPAGE_ACTIVATE. Other ->writepages() don't have to deal with this because their ->writepage() won't return AOP_WRITEPAGE_ACTIVATE at all. But it is going to be ugly to specialize the first locked page in every ->writepages() functions.. > > > > I'd like to just ignore the shmem case, by adding a > > bdi_cap_writeback_dirty() check. Because clustered writing to swap > > device may be a less gain. > > Or you can just call try_to_unmap() from shmem_writepage() when > wbc->for_reclaim is true. Hmm, it's more comfortable to stay away from shmem for the initial version. But feel free to submit a patch for it in future :) > > Page filtering should also be possible in write_cache_pages(). But > > what do you mean by "hard-to-fix races against inode reclamation"? > > vmscan.c pageout path doesn't take a reference on inode, so the > instant ->writepage() releases lock on the page, the inode can be > freed. Ah, then we could just do igrab() if inode_lock is not locked? A bit ugly though. Thanks, Fengguang -- 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
