Re: [Patch] invalidate range of pages after direct IO write
From: Zach Brown
Date: Thu Feb 03 2005 - 20:59:33 EST
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
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()
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/