On Wed, 26 Aug 2009, Nikita Danilov wrote:

> Vincent Li <macli@brc.ubc.ca> writes:
> 
> > On Wed, 26 Aug 2009, Christoph Hellwig wrote:
> >
> >> On Tue, Aug 25, 2009 at 03:18:08PM -0700, Vincent Li wrote:
> >> > Commit 543ade1fc9 (Streamline generic_file_* interfaces and filemap cleanups)
> >> > removed generic_file_write() in filemap. For consistency, change the comment in
> >> > vmscan pageout() to do_sync_write().
> >>
> >> I think the right replacement would be __generic_file_aio_write.  But
> >
> > There is no __generic_file_aio_write, but __generic_file_aio_write_nolock,
> > generic_file_aio_write and generic_file_aio_write_nolock.
> >
> > I read the commit 543ade1fc9, it seems it replaced all .write = generic_file_write to
> > .write = do_sync_write. I thought they are the same.
> >
> >> from a quick glance over the code don't have the slightest idea what it
> >> is referring to.
> >
> > I read the code  over and over again, still no clue about the comment :-(.
> 
> This comment is about (bdi == current->backing_dev_info) condition in may_write_to_queue(),
> checking against
> 
>     /* We can write back this queue in page reclaim */
>     current->backing_dev_info = mapping->backing_dev_info;
> 
> bit (that used to be?) in __generic_file_aio_write_nolock()
> 
> Thank you,
> Nikita.

Thank you for the explaintion!

	* If this process is currently in generic_file_write() against
	* this page's queue, we can perform writeback even if that
	* will block.

So my interpretation for the comment is that if the current process is 
already in __generic_file_aio_write against the page's queue, The page 
claim path code can still perfom writeback even if the __generic_file_aio_write 
will block. Am I right?


Vincent Li
Biomedical Research Center
University of British Columbia