All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Glauber Costa <glauber@scylladb.com>
Cc: Avi Kivity <avi@scylladb.com>, Brian Foster <bfoster@redhat.com>,
	xfs@oss.sgi.com
Subject: Re: sleeps and waits during io_submit
Date: Wed, 2 Dec 2015 08:39:36 +1100	[thread overview]
Message-ID: <20151201213936.GA19199@dastard> (raw)
In-Reply-To: <CAD-J=zbZdWkJ8sfJHyKmQTZYVvLFbqbbEbWo2HV25jnZyrfTaA@mail.gmail.com>

On Tue, Dec 01, 2015 at 04:10:45PM -0500, Glauber Costa wrote:
> On Tue, Dec 1, 2015 at 4:04 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Dec 01, 2015 at 05:22:38PM +0200, Avi Kivity wrote:
> >> On 12/01/2015 04:56 PM, Brian Foster wrote:
> >> mount -o discard.  And yes, overwrites are supposedly more expensive
> >> than trim old data + allocate new data, but maybe if you compare it
> >> with the work XFS has to do, perhaps the tradeoff is bad.
> >
> > Oh, you do realise that using "-o discard" causes significant delays
> > in journal commit processing? i.e. the journal commit completion
> > blocks until all the discards have been submitted and waited on
> > *synchronously*. This is a problem with the linux block layer in
> > that blkdev_issue_discard() is a synchronous operation.....
> >
> > Hence if you are seeing delays in transactions (e.g. timestamp updates)
> > it's entirely possible that things will get much better if you
> > remove the discard mount option. It's much better from a performance
> > perspective to use the fstrim command every so often - fstrim issues
> > discard operations in the context of the fstrim process - it does
> > not interact with the transaction subsystem at all.
> 
> Hi Dave,
> 
> This is news to me.
> 
> However, in the disk that we have used during the acquisition of this
> trace, discard doesn't seem to be supported:
> $ sudo fstrim /data/
> fstrim: /data/: the discard operation is not supported
> 
> In that case, if I understand correctly the discard mount option
> should be a noop, no?

XFS still makes the blkdev_issue_discard() calls, though, because
the block device can turn discard support on and off dynamically.
e.g. raid devices where a faulty drive is replaced temporarily with
a drive that doesn't have discard support. The block device suddenly
starts returning -EOPNOTSUPP to the filesystem from
blkdev_issue_discard() calls. However, the admin then replaces that
drive with a new one that des have discard support, and now
blkdev_issue_discard() works as exepected.

IOWs, if you set the mount option, XFS will always attempt to issue
discards...

> That recommendation is great for our general case, though.

For the moment. Given lots of time, reworking this code could
greatly reduce the impact/overhead of it and so make it practical to
enable. There's a lot of work to get to that point, though...

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-12-01 21:39 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28  2:43 sleeps and waits during io_submit Glauber Costa
2015-11-30 14:10 ` Brian Foster
2015-11-30 14:29   ` Avi Kivity
2015-11-30 16:14     ` Brian Foster
2015-12-01  9:08       ` Avi Kivity
2015-12-01 13:11         ` Brian Foster
2015-12-01 13:58           ` Avi Kivity
2015-12-01 14:01             ` Glauber Costa
2015-12-01 14:37               ` Avi Kivity
2015-12-01 20:45               ` Dave Chinner
2015-12-01 20:56                 ` Avi Kivity
2015-12-01 23:41                   ` Dave Chinner
2015-12-02  8:23                     ` Avi Kivity
2015-12-01 14:56             ` Brian Foster
2015-12-01 15:22               ` Avi Kivity
2015-12-01 16:01                 ` Brian Foster
2015-12-01 16:08                   ` Avi Kivity
2015-12-01 16:29                     ` Brian Foster
2015-12-01 17:09                       ` Avi Kivity
2015-12-01 18:03                         ` Carlos Maiolino
2015-12-01 19:07                           ` Avi Kivity
2015-12-01 21:19                             ` Dave Chinner
2015-12-01 21:38                               ` Avi Kivity
2015-12-01 23:06                                 ` Dave Chinner
2015-12-02  9:02                                   ` Avi Kivity
2015-12-02 12:57                                     ` Carlos Maiolino
2015-12-02 23:19                                     ` Dave Chinner
2015-12-03 12:52                                       ` Avi Kivity
2015-12-04  3:16                                         ` Dave Chinner
2015-12-08 13:52                                           ` Avi Kivity
2015-12-08 23:13                                             ` Dave Chinner
2015-12-01 18:51                         ` Brian Foster
2015-12-01 19:07                           ` Glauber Costa
2015-12-01 19:35                             ` Brian Foster
2015-12-01 19:45                               ` Avi Kivity
2015-12-01 19:26                           ` Avi Kivity
2015-12-01 19:41                             ` Christoph Hellwig
2015-12-01 19:50                               ` Avi Kivity
2015-12-02  0:13                             ` Brian Foster
2015-12-02  0:57                               ` Dave Chinner
2015-12-02  8:38                                 ` Avi Kivity
2015-12-02  8:34                               ` Avi Kivity
2015-12-08  6:03                                 ` Dave Chinner
2015-12-08 13:56                                   ` Avi Kivity
2015-12-08 23:32                                     ` Dave Chinner
2015-12-09  8:37                                       ` Avi Kivity
2015-12-01 21:04                 ` Dave Chinner
2015-12-01 21:10                   ` Glauber Costa
2015-12-01 21:39                     ` Dave Chinner [this message]
2015-12-01 21:24                   ` Avi Kivity
2015-12-01 21:31                     ` Glauber Costa
2015-11-30 15:49   ` Glauber Costa
2015-12-01 13:11     ` Brian Foster
2015-12-01 13:39       ` Glauber Costa
2015-12-01 14:02         ` Brian Foster
2015-11-30 23:10 ` Dave Chinner
2015-11-30 23:51   ` Glauber Costa
2015-12-01 20:30     ` 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=20151201213936.GA19199@dastard \
    --to=david@fromorbit.com \
    --cc=avi@scylladb.com \
    --cc=bfoster@redhat.com \
    --cc=glauber@scylladb.com \
    --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.