summaryrefslogtreecommitdiffstats
path: root/block
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2017-07-31 10:29:38 -0400
committerJeff Layton <jlayton@redhat.com>2017-08-01 08:39:29 -0400
commitffb959bbdf923b4f89a08a04aba2501b1b16d164 (patch)
treefa248b66c3b36982ee41ca1c51807b453b4d9e22 /block
parent3b49c9a1e984b524142afc7536041d8c66877113 (diff)
downloadlinux-ffb959bbdf923b4f89a08a04aba2501b1b16d164.tar.gz
linux-ffb959bbdf923b4f89a08a04aba2501b1b16d164.tar.bz2
linux-ffb959bbdf923b4f89a08a04aba2501b1b16d164.zip
mm: remove optimizations based on i_size in mapping writeback waits
Marcelo added this i_size based optimization with a patch in 2004 (commitid is from the linux-history tree): commit 765dad09b4ac101a32d87af2bb793c3060497d3c Author: Marcelo Tosatti <marcelo.tosatti@cyclades.com> Date: Tue Sep 7 17:51:17 2004 -0700 small wait_on_page_writeback_range() optimization filemap_fdatawait() calls wait_on_page_writeback_range() with -1 as "end" parameter. This is not needed since we know the EOF from the inode. Use that instead. There may be races here, particularly with clustered or network filesystems. It also seems like a bit of a layering violation since we're operating on an address_space here, not an inode. Finally, it's also questionable whether this optimization really helps on workloads that we care about. Should we be optimizing for writeback vs. truncate races in a codepath where we expect to wait anyway? It doesn't seem worth the risk. Remove this optimization from the filemap_fdatawait codepaths. This means that filemap_fdatawait becomes a trivial wrapper around filemap_fdatawait_range. Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Jeff Layton <jlayton@redhat.com>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions