From: Jeff Layton <jlayton@redhat.com>
To: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] mm: remove optimizations based on i_size in mapping writeback waits
Date: Tue, 01 Aug 2017 07:16:37 -0400 [thread overview]
Message-ID: <1501586197.4702.5.camel@redhat.com> (raw)
In-Reply-To: <20170801090404.GA4215@quack2.suse.cz>
On Tue, 2017-08-01 at 11:04 +0200, Jan Kara wrote:
> On Mon 31-07-17 11:29:46, Jeff Layton wrote:
> > From: Jeff Layton <jlayton@redhat.com>
> >
> > Marcelo added this i_size based optimization with a patch in 2004
> > (commit 765dad09b4ac in 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. Block devices always have an i_size of 0 as well, which
> > makes using this with a blockdev inode sort of pointless.
>
> Well, you are not quite right here. You are correct that
> file_inode(file)->i_size is 0, however file->f_mapping->host->i_size is the
> device size and that's what will be used for filemap_fdatawait(). So that
> function works fine for block devices.
>
Got it. I'll fix up the description, but I won't bother re-posting for
that.
> > 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.
>
> Agreed for all the other reasons so feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> Honza
>
> >
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > include/linux/fs.h | 9 +++++++--
> > mm/filemap.c | 30 +-----------------------------
> > 2 files changed, 8 insertions(+), 31 deletions(-)
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index af592ca3d509..656e04c6983e 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -2538,10 +2538,15 @@ extern int invalidate_inode_pages2_range(struct address_space *mapping,
> > extern int write_inode_now(struct inode *, int);
> > extern int filemap_fdatawrite(struct address_space *);
> > extern int filemap_flush(struct address_space *);
> > -extern int filemap_fdatawait(struct address_space *);
> > -extern int filemap_fdatawait_keep_errors(struct address_space *mapping);
> > extern int filemap_fdatawait_range(struct address_space *, loff_t lstart,
> > loff_t lend);
> > +extern int filemap_fdatawait_keep_errors(struct address_space *mapping);
> > +
> > +static inline int filemap_fdatawait(struct address_space *mapping)
> > +{
> > + return filemap_fdatawait_range(mapping, 0, LLONG_MAX);
> > +}
> > +
> > extern bool filemap_range_has_page(struct address_space *, loff_t lstart,
> > loff_t lend);
> > extern int __must_check file_fdatawait_range(struct file *file, loff_t lstart,
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 394bb5e96f87..85dfe3bee324 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -512,39 +512,11 @@ EXPORT_SYMBOL(file_fdatawait_range);
> > */
> > int filemap_fdatawait_keep_errors(struct address_space *mapping)
> > {
> > - loff_t i_size = i_size_read(mapping->host);
> > -
> > - if (i_size == 0)
> > - return 0;
> > -
> > - __filemap_fdatawait_range(mapping, 0, i_size - 1);
> > + __filemap_fdatawait_range(mapping, 0, LLONG_MAX);
> > return filemap_check_and_keep_errors(mapping);
> > }
> > EXPORT_SYMBOL(filemap_fdatawait_keep_errors);
> >
> > -/**
> > - * filemap_fdatawait - wait for all under-writeback pages to complete
> > - * @mapping: address space structure to wait for
> > - *
> > - * Walk the list of under-writeback pages of the given address space
> > - * and wait for all of them. Check error status of the address space
> > - * and return it.
> > - *
> > - * Since the error status of the address space is cleared by this function,
> > - * callers are responsible for checking the return value and handling and/or
> > - * reporting the error.
> > - */
> > -int filemap_fdatawait(struct address_space *mapping)
> > -{
> > - loff_t i_size = i_size_read(mapping->host);
> > -
> > - if (i_size == 0)
> > - return 0;
> > -
> > - return filemap_fdatawait_range(mapping, 0, i_size - 1);
> > -}
> > -EXPORT_SYMBOL(filemap_fdatawait);
> > -
> > static bool mapping_needs_writeback(struct address_space *mapping)
> > {
> > return (!dax_mapping(mapping) && mapping->nrpages) ||
> > --
> > 2.13.3
> >
Thanks!
--
Jeff Layton <jlayton@redhat.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2017-08-01 11:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 15:29 [PATCH] mm: remove optimizations based on i_size in mapping writeback waits Jeff Layton
2017-08-01 9:04 ` Jan Kara
2017-08-01 11:16 ` Jeff Layton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1501586197.4702.5.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtosatti@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).