linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Dmitry Monakhov <dmonakhov@openvz.org>,
	Jeff Moyer <jmoyer@redhat.com>
Subject: Re: [PATCH 1/3] blkdev: Submit discard bio in batches in  blkdev_issue_discard()
Date: Mon, 2 May 2011 10:23:20 -0600	[thread overview]
Message-ID: <4DBEDA78.7020502@fusionio.com> (raw)
In-Reply-To: <1304345841-20063-1-git-send-email-lczerner@redhat.com>

On 2011-05-02 08:17, Lukas Czerner wrote:
> Currently we are waiting for every submitted REQ_DISCARD bio separately,
> but it can have unwanted consequences of repeatedly flushing the queue,
> so we rather submit bios in batches and wait for the entire batch, hence
> narrowing the window of other ios going in.
> 
> Use bio_batch_end_io() and struct bio_batch for that purpose, the same
> is used by blkdev_issue_zeroout(). Also change bio_batch_end_io() so we
> always set !BIO_UPTODATE in the case of error and remove the check for
> bb, since we are the only user of this function and we always set this.
> 
> Remove bio_get()/bio_put() from the blkdev_issue_discard() since
> bio_alloc() and bio_batch_end_io() is doing the same thing, hence it is
> not needed anymore.
> 
> I have done simple dd testing with surprising results. The script I have
> used is:
> 
> for i in $(seq 10); do
>         echo $i
>         dd if=/dev/sdb1 of=/dev/sdc1 bs=4k &
>         sleep 5
> done
> /usr/bin/time -f %e ./blkdiscard /dev/sdc1
> 
> Running time of BLKDISCARD on the whole device:
> with patch              without patch
> 0.95                    15.58
> 
> So we can see that in this artificial test the kernel with the patch
> applied is approx 16x faster in discarding the device.

Good results. It'd be more efficient to add the vectored discard support
and use it for this too though, and it would get rid of the need to wait
on the batches since there'd be just one discard bio for the ranges.

-- 
Jens Axboe


  parent reply	other threads:[~2011-05-02 17:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 14:17 [PATCH 1/3] blkdev: Submit discard bio in batches in blkdev_issue_discard() Lukas Czerner
2011-05-02 14:17 ` [PATCH 2/3] blkdev: Simple cleanup in blkdev_issue_zeroout() Lukas Czerner
2011-05-02 14:17 ` [PATCH 3/3] blkdev: honor discard_granularity in blkdev_issue_discard() Lukas Czerner
2011-05-02 14:38   ` Martin K. Petersen
2011-05-02 16:10     ` Jeff Moyer
2011-05-02 17:07       ` Martin K. Petersen
2011-05-02 23:21     ` Dave Chinner
2011-05-02 16:23 ` Jens Axboe [this message]
2011-05-03  9:30   ` [PATCH 1/3] blkdev: Submit discard bio in batches " Lukas Czerner
2011-05-03  9:57     ` Christoph Hellwig
2011-05-07  1:23     ` Jens Axboe
2011-05-05 15:20   ` Lukas Czerner
2011-05-07  1:24     ` Jens Axboe
2011-05-09 14:30     ` Christoph Hellwig
2011-05-05 15:12 ` [PATCH] blkdev: Do not return -EOPNOTSUPP if discard is supported Lukas Czerner
2011-05-07  1:30   ` Jens Axboe

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=4DBEDA78.7020502@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=dmonakhov@openvz.org \
    --cc=jmoyer@redhat.com \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).