public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <koverstreet@google.com>
To: Jens Axboe <jaxboe@fusionio.com>
Cc: Jack Wang <jack.wang.usish@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-aio@kvack.org" <linux-aio@kvack.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"zab@redhat.com" <zab@redhat.com>,
	"bcrl@kvack.org" <bcrl@kvack.org>,
	"jmoyer@redhat.com" <jmoyer@redhat.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 00/26] AIO performance improvements/cleanups, v2
Date: Tue, 18 Dec 2012 11:16:33 -0800	[thread overview]
Message-ID: <20121218191633.GB24548@google.com> (raw)
In-Reply-To: <50CC7840.4090403@fusionio.com>

On Sat, Dec 15, 2012 at 02:16:48PM +0100, Jens Axboe wrote:
> On 2012-12-15 11:36, Kent Overstreet wrote:
> >> Knock yourself out - I already took a quick look at it, and conversion
> >> should be pretty simple. It's the mtip32xx driver, it's in the kernel. I
> >> would suggest getting rid of the ->async_callback() (since it's always
> >> bio_endio()) since that'll make it cleaner.
> > 
> > Just pushed my conversion - it's untested, but it's pretty
> > straightforward.
> 
> You forgot a batch_complete_init(). With that, it works. Single device
> is ~1050K now, so still slower than jaio without batching (which was
> ~1220K).  But it's an improvement over kaio-dio, which was roughly ~930K
> IOPS.

Curious... if the device is delivering a reasonable number of
completions per interrupt, I would've expected that to help more (it
made a huge difference for me). Now I'm really curious where the
difference is coming from.

It's possible something I did introduced a performance regression you're
uncovering (i.e. I reordered stuff in struct kiocb to shrink it, not
sure if you were testing with those changes). It sounds like the
mtip32xx driver is better/more efficient than anything I can test with,
so if so it's entirely possible you're seing it due to less noise there.

Or maybe just getting rid of the ringbuffer is that awesome. Gonna try
and work on combining our optimizations so I can see what that looks
like :)

  reply	other threads:[~2012-12-18 19:23 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-03 20:58 [PATCH 00/26] AIO performance improvements/cleanups, v2 Kent Overstreet
2012-12-03 20:58 ` [PATCH 01/26] mm: remove old aio use_mm() comment Kent Overstreet
2012-12-03 20:58 ` [PATCH 02/26] aio: remove dead code from aio.h Kent Overstreet
2012-12-03 20:58 ` [PATCH 03/26] gadget: remove only user of aio retry Kent Overstreet
2012-12-03 20:58 ` [PATCH 04/26] aio: remove retry-based AIO Kent Overstreet
2012-12-27 10:11   ` Fubo Chen
2012-12-03 20:58 ` [PATCH 05/26] char: add aio_{read,write} to /dev/{null,zero} Kent Overstreet
2012-12-03 20:58 ` [PATCH 06/26] aio: Kill return value of aio_complete() Kent Overstreet
2012-12-03 20:58 ` [PATCH 07/26] aio: kiocb_cancel() Kent Overstreet
2012-12-03 20:58 ` [PATCH 08/26] aio: Move private stuff out of aio.h Kent Overstreet
2012-12-03 20:58 ` [PATCH 09/26] aio: dprintk() -> pr_debug() Kent Overstreet
2012-12-03 20:58 ` [PATCH 10/26] aio: do fget() after aio_get_req() Kent Overstreet
2012-12-03 20:58 ` [PATCH 11/26] aio: Make aio_put_req() lockless Kent Overstreet
2012-12-03 20:58 ` [PATCH 12/26] aio: Refcounting cleanup Kent Overstreet
2012-12-03 20:58 ` [PATCH 13/26] aio: Convert read_events() to hrtimers Kent Overstreet
2012-12-03 20:58 ` [PATCH 14/26] aio: Make aio_read_evt() more efficient Kent Overstreet
2012-12-03 20:58 ` [PATCH 15/26] aio: Use flush_dcache_page() Kent Overstreet
2012-12-03 20:58 ` [PATCH 16/26] aio: Use cancellation list lazily Kent Overstreet
2012-12-03 20:58 ` [PATCH 17/26] aio: Change reqs_active to include unreaped completions Kent Overstreet
2012-12-03 20:58 ` [PATCH 18/26] aio: Kill batch allocation Kent Overstreet
2012-12-03 20:58 ` [PATCH 19/26] aio: Kill struct aio_ring_info Kent Overstreet
2012-12-03 20:58 ` [PATCH 20/26] aio: Give shared kioctx fields their own cachelines Kent Overstreet
2012-12-03 20:58 ` [PATCH 21/26] aio: reqs_active -> reqs_available Kent Overstreet
2012-12-03 20:58 ` [PATCH 22/26] aio: percpu reqs_available Kent Overstreet
2012-12-03 20:58 ` [PATCH 23/26] Generic dynamic per cpu refcounting Kent Overstreet
2012-12-27 13:47   ` Fubo Chen
2012-12-03 20:58 ` [PATCH 24/26] aio: Percpu ioctx refcount Kent Overstreet
2012-12-03 20:58 ` [PATCH 25/26] aio: use xchg() instead of completion_lock Kent Overstreet
2012-12-03 20:58 ` [PATCH 26/26] aio: Don't include aio.h in sched.h Kent Overstreet
2012-12-13 21:18 ` [PATCH 00/26] AIO performance improvements/cleanups, v2 Jens Axboe
2012-12-14  2:26   ` Jack Wang
2012-12-14  7:35     ` Jens Axboe
2012-12-15  9:25       ` Kent Overstreet
2012-12-15  9:46         ` Jens Axboe
2012-12-15 10:36           ` Kent Overstreet
2012-12-15 12:59             ` Jens Axboe
2012-12-15 13:16             ` Jens Axboe
2012-12-18 19:16               ` Kent Overstreet [this message]
2012-12-19  6:45                 ` Kent Overstreet

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=20121218191633.GB24548@google.com \
    --to=koverstreet@google.com \
    --cc=bcrl@kvack.org \
    --cc=jack.wang.usish@gmail.com \
    --cc=jaxboe@fusionio.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zab@redhat.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