From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages()
Date: Wed, 3 Aug 2011 17:42:06 -0400 [thread overview]
Message-ID: <20110803214206.GA20477@infradead.org> (raw)
In-Reply-To: <1312404545-15400-1-git-send-email-jack@suse.cz>
On Wed, Aug 03, 2011 at 10:49:03PM +0200, Jan Kara wrote:
>
> Hi,
>
> at one of customer's machines, I've spotted an issue that sync(1) called
> after writing a single huge file has been achieving rather low throughput. After
> debugging this with blktrace, I've found that the culprit was in flusher thread
> racing with page writeout happening from XFS sync code. The patches below helped
> that case. Although they are not a complete solution, I belive they are useful
> anyway so please consider merging them...
We currently have three calls to xfs_flush_pages with XBF_ASYNC set:
- xfs_setattr_size
- xfs_sync_inode_data
- xfs_release
The first one actually is a synchronous writeout, just implemented in
a rather odd way by doing the xfs_ioend_wait right after it, so your
change is actively harmful for it. The second is only called from
xfs_flush_worker, which is the workqueue offload when we hit ENOSPC.
I can see how this might race with the writeback code, but the correct
fix is to replace it with a call to writeback_inodes_sb(_if_idle)
on that one is fixed to do a trylock on s_umount and thus won't
deadlock. The third one is opportunistic writeout if a file got
truncated down on final release. filemap_flush probably is fine
here, but there's no need for a range version. If you replace it
with filemap_flush please also kill the useless wrapper while you're
at it.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: hch@infradead.org, xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/2] Improve writeout pattern from xfs_flush_pages()
Date: Wed, 3 Aug 2011 17:42:06 -0400 [thread overview]
Message-ID: <20110803214206.GA20477@infradead.org> (raw)
In-Reply-To: <1312404545-15400-1-git-send-email-jack@suse.cz>
On Wed, Aug 03, 2011 at 10:49:03PM +0200, Jan Kara wrote:
>
> Hi,
>
> at one of customer's machines, I've spotted an issue that sync(1) called
> after writing a single huge file has been achieving rather low throughput. After
> debugging this with blktrace, I've found that the culprit was in flusher thread
> racing with page writeout happening from XFS sync code. The patches below helped
> that case. Although they are not a complete solution, I belive they are useful
> anyway so please consider merging them...
We currently have three calls to xfs_flush_pages with XBF_ASYNC set:
- xfs_setattr_size
- xfs_sync_inode_data
- xfs_release
The first one actually is a synchronous writeout, just implemented in
a rather odd way by doing the xfs_ioend_wait right after it, so your
change is actively harmful for it. The second is only called from
xfs_flush_worker, which is the workqueue offload when we hit ENOSPC.
I can see how this might race with the writeback code, but the correct
fix is to replace it with a call to writeback_inodes_sb(_if_idle)
on that one is fixed to do a trylock on s_umount and thus won't
deadlock. The third one is opportunistic writeout if a file got
truncated down on final release. filemap_flush probably is fine
here, but there's no need for a range version. If you replace it
with filemap_flush please also kill the useless wrapper while you're
at it.
next prev parent reply other threads:[~2011-08-03 21:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 20:49 [PATCH 0/2] Improve writeout pattern from xfs_flush_pages() Jan Kara
2011-08-03 20:49 ` Jan Kara
2011-08-03 20:49 ` [PATCH 1/2] vfs: Create filemap_flush_range() Jan Kara
2011-08-03 20:49 ` Jan Kara
2011-08-03 20:49 ` [PATCH 2/2] xfs: Call filemap_flush_range() for async xfs_flush_pages() call Jan Kara
2011-08-03 20:49 ` Jan Kara
2011-08-03 22:03 ` Christoph Hellwig
2011-08-03 22:03 ` Christoph Hellwig
2011-08-03 22:34 ` Vivek Goyal
2011-08-03 22:34 ` Vivek Goyal
2011-08-04 10:03 ` Jan Kara
2011-08-04 10:03 ` Jan Kara
2011-08-03 21:42 ` Christoph Hellwig [this message]
2011-08-03 21:42 ` [PATCH 0/2] Improve writeout pattern from xfs_flush_pages() Christoph Hellwig
2011-08-04 10:36 ` Jan Kara
2011-08-04 10:36 ` Jan Kara
2011-08-04 10:42 ` Christoph Hellwig
2011-08-04 10:42 ` Christoph Hellwig
2011-08-04 12:07 ` Jan Kara
2011-08-04 12:07 ` Jan Kara
2011-08-04 12:19 ` Christoph Hellwig
2011-08-04 12:19 ` Christoph Hellwig
2011-08-04 12:37 ` Jan Kara
2011-08-04 12:37 ` Jan Kara
2011-08-04 12:41 ` Christoph Hellwig
2011-08-04 12:41 ` Christoph Hellwig
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=20110803214206.GA20477@infradead.org \
--to=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.