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: Wed, 11 Nov 2015 10:25:43 +1100 [thread overview]
Message-ID: <20151110232543.GH14311@dastard> (raw)
In-Reply-To: <20150901074103.GA27231@infradead.org>
[ finally getting back to this :/ ]
On Tue, Sep 01, 2015 at 12:41:03AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 01, 2015 at 08:17:43AM +1000, Dave Chinner wrote:
> > 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.
>
> I've spend time to look over the patch again, and still don't see
> a change.
Ah, it's in the next patch that I haven't posted that "goes straight
to bios". Ignore it for now...
> > 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.
>
> .. that we now build up way bigger ioend chains.
>
> So back to Brians concern: we can now have fairly large piles of
> ioends built up while potentially getting scheduled out, and this
> does look like a potential real issue to me. I wonder if we should
> (ab-)use the blk_plug_cb infrastructure so that we can flush the
> pending ioends out on a context switch?
Possibly, but I'm thinking that we should just end up building bios
directly and submitting them once they are reach size limits of
boundaries rather than building ioend chains for later submission.
Did the work for arbitrarily sized bios ever get merged? I can't
find any evidence that it did....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-11-10 23:26 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
2015-09-01 7:41 ` Christoph Hellwig
2015-11-10 23:25 ` Dave Chinner [this message]
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=20151110232543.GH14311@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