public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Brian Foster <bfoster@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 2/4] xfs: Introduce writeback context for writepages
Date: Tue, 1 Sep 2015 08:17:43 +1000	[thread overview]
Message-ID: <20150831221743.GI26895@dastard> (raw)
In-Reply-To: <20150831185612.GB349@infradead.org>

On Mon, Aug 31, 2015 at 11:56:12AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 31, 2015 at 02:02:22PM -0400, Brian Foster wrote:
> > Ok, but the comment for blk_start_plug() mentions some kind of flush on
> > task sleep mechanism. I could be wrong, but I take this to mean there
> > are cases where I/O can initiate before the plug is stopped. Does
> > deferring the I/O submission across writepages defeat that heuristic in
> > any way? My (preliminary) understanding is that while the I/O submission
> > would still be deferred by the plug in the same way in most cases, we're
> > potentially holding back I/Os from the block infrastructure until the
> > entire writepages sequence is complete.
> 
> Yes, we do.  But the reason why the block layer needs to flush the
> plug on context switch is because we only have a limited bio mempool,
> and if processes that are not running consume that we can't make
> guaranteed progress.  The XFS writeback code doesn't allocate bios
> until the end we are not affected by that particular issues, although
> we still need to worry about our own ioend mempools.

The patch changes the bio allocation patterns - it allocates them on
the fly and holds them, so we could potentially exhaust the bio
mempool with this submission technique. The ioend allocation pattern
is different, too, because we only used to have 1 per buffer on a
writepage call and the last one was used for the write clustering.

> Sidenote:  Jens now has the arbitrarily sized bio code in his queue
> for 4.3.  With that we could replace our ioends with bios that have
> a little private data and simplify the submission phase of the
> writeback code significantly.

Yes, I've been keeping an eye on that and waiting for it to land as
it solves many of the above problems. I still wanted to get the write
cluster infrastructure changes underway, though, so I can work
on making the writeback path not use bufferheads at all...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-08-31 22:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-25  5:05 [PATCH 0/4 v2] xfs: get rid of xfs_cluster_write() Dave Chinner
2015-08-25  5:05 ` [PATCH 1/4] xfs: remove nonblocking mode from xfs_vm_writepage Dave Chinner
2015-08-31 18:41   ` Christoph Hellwig
2015-08-25  5:05 ` [PATCH 2/4] xfs: Introduce writeback context for writepages Dave Chinner
2015-08-31 18:02   ` Brian Foster
2015-08-31 18:56     ` Christoph Hellwig
2015-08-31 22:17       ` Dave Chinner [this message]
2015-09-01  7:41         ` Christoph Hellwig
2015-11-10 23:25           ` Dave Chinner
2015-11-11 11:32             ` Christoph Hellwig
2016-02-08  7:36   ` Christoph Hellwig
2016-02-08  7:54     ` Christoph Hellwig
2016-02-08 20:21       ` Dave Chinner
2016-02-09  9:11         ` Christoph Hellwig
2015-08-25  5:05 ` [PATCH 3/4] xfs: xfs_cluster_write is redundant Dave Chinner
2015-08-25  5:05 ` [PATCH 4/4] xfs: factor mapping out of xfs_do_writepage Dave Chinner

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=20150831221743.GI26895@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=hch@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox