Re: [PATCH 30/45] vmscan: lumpy pageout

[Wu Fengguang <fengguang.wu@intel.com>]

On Wed, Oct 07, 2009 at 07:37:35PM +0800, Nikita Danilov wrote:
> 2009/10/7 Wu Fengguang <fengguang.wu@intel.com>:
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html