Re: [Patch] invalidate range of pages after direct IO write

[Zach Brown <zach.brown@oracle.com>]

Andrew Morton wrote:

> Note that the same optimisation should be made in the call to
> unmap_mapping_range() in generic_file_direct_IO().  Currently we try and
> unmap the whole file, even if we're only writing a single byte.  Given that
> you're now calculating iov_length() in there we might as well use that
> number a few lines further up in that function.

Indeed.  I can throw that together.  I also have a patch that introduces
 filemap_write_and_wait_range() and calls it from the read bit of
__blockdev_direct_IO().  It didn't change the cheesy fsx load I was
using and then I got distracted.  I can try harder.

> Reading the code, I'm unable to convince myself that it won't go into an
> infinite loop if it finds a page at page->index = -1.  But I didn't try
> very hard ;)

I'm unconvinced as well. I got the pattern from
truncate_inode_pages_range() and it seems to have a related problem when
end is something that page_index can never be greater than.  It just
starts over.

I wonder if we should add some mapping_for_each_range() (less ridiculous
names welcome :)) macro that handles this crap for the caller who just
works with page pointers.  We could introduce some iterator struct that
the caller would put on the stack and pass in to hold state, something
like the 'n' in list_for_each_safe().  It looks like a few
pagevec_lookup() callers could use this.

> Minor note on this:
> 
> 	return invalidate_inode_pages2_range(mapping, 0, ~0UL);
> 
> I just use `-1' there.

Roger.  I was just mimicking invalidate_inode_pages().

> I'll make that change and plop the patch into -mm, but we need to think
> about the infinite-loop problem..

I can try hacking together that macro and auditing pagevec_lookup()
callers..

- z