diff options
author | Jeff Layton <jlayton@redhat.com> | 2017-07-31 10:29:38 -0400 |
---|---|---|
committer | Jeff Layton <jlayton@redhat.com> | 2017-08-01 08:39:29 -0400 |
commit | ffb959bbdf923b4f89a08a04aba2501b1b16d164 (patch) | |
tree | fa248b66c3b36982ee41ca1c51807b453b4d9e22 /block | |
parent | 3b49c9a1e984b524142afc7536041d8c66877113 (diff) | |
download | linux-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