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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
