mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: zach.brown@oracle.com
Cc: linux-aio <linux-aio@kvack.org>,
	Linux Kernel Mailing <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [patch v4 0/3] aio: implement request batching
Date: Fri, 02 Oct 2009 18:54:20 -0400	[thread overview]
Message-ID: <x49zl8976g3.fsf@segfault.boston.devel.redhat.com> (raw)

Hi,

In this, the 4th iteration of the patch set, I've addressed the concerns
of Jens and Zach as follows:

- In the O_DIRECT write path, we get rid of WRITE_ODIRECT in favor of
  WRITE_SYNC_PLUG
- request batching is only done for AIO operations that could
  potentially benefit from it
- Initialization of the hash table is done using the gcc array
  initialization syntax

Further, I got rid of a compiler warning that I had introduced in the
last patch set.  I'll continue to test this under a variety of loads,
but would certainly appreciate it if others could give it a spin.

Patch overview / reason for existence:

Some workloads issue batches of small I/Os, and the performance is poor
due to the call to blk_run_address_space for every single iocb.  Nathan
Roberts pointed this out, and suggested that by deferring this call
until all I/Os in the iocb array are submitted to the block layer, we
can realize some impressive performance gains.

For example, running against a simple SATA disk driving a queue depth of
128, we can improve the performance of O_DIRECT writes twofold for 4k
I/Os, and similarly impressive numbers for other I/O sizes:
  http://people.redhat.com/jmoyer/dbras/vanilla-vs-v4/metallica-single-sata/noop/io-depth-128-write-bw.png

For read workloads on somewhat faster storage, we see similar benefits
for batches of smaller I/Os as well:
  http://people.redhat.com/jmoyer/dbras/vanilla-vs-v4/thor-4-disk-lvm-stripe/noop/io-depth-16-read-bw.png
That's 230+MB/s for vanilla 4k reads, batches of 16 vs. 410MB/s for
patched.  When there are multiple threads competing for the disk, I
haven't witnessed such crazy numbers, however.

Cheers,
Jeff

             reply	other threads:[~2009-10-02 22:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 22:54 Jeff Moyer [this message]
2009-10-02 22:56 ` [patch v4 1/2] block: get rid of the WRITE_ODIRECT flag Jeff Moyer
2009-10-02 22:57 ` [patch v4 2/2] aio: implement request batching Jeff Moyer
2009-10-02 22:58 ` [patch v4 0/3] " Jeff Moyer
2009-10-06 17:45 ` [patch v4 0/3] aio: implement request batching [more performance numbers] Jeff Moyer
2009-10-06 18:06   ` Jens Axboe
2009-10-06 18:18     ` Jeff Moyer
2009-10-07 10:52       ` Jens Axboe
2009-10-07 12:09         ` Jeff Moyer
2009-10-27 16:16         ` Jeff Moyer
2009-10-28  8:28           ` 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=x49zl8976g3.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach.brown@oracle.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

all inboxes | Powered by JetHome®