From: Jens Axboe <axboe@kernel.dk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
martin.peterson@oracle.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v1 7/7] xen-block: implement indirect descriptors
Date: Thu, 18 Apr 2013 05:43:55 -0700 [thread overview]
Message-ID: <20130418124355.GW4816@kernel.dk> (raw)
In-Reply-To: <20130417172747.GA25736@phenom.dumpdata.com>
On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
> > On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
> > >>> Perhaps the xen-blkfront part of the patch should be just split out to make
> > >>> this easier?
> > >>>
> > >>> Perhaps what we really should have is just the 'max' value of megabytes
> > >>> we want to handle on the ring.
> > >>>
> > >>> As right now 32 ring requests * 32 segments = 4MB. But if the user wants
> > >>> to se the max: 32 * 4096 = so 512MB (right? each request would handle now 16MB
> > >>> and since we have 32 of them = 512MB).
> > >>
> > >> I've just set that to something that brings a performance benefit
> > >> without having to map an insane number of persistent grants in blkback.
> > >>
> > >> Yes, the values are correct, but the device request queue (rq) is only
> > >> able to provide read requests with 64 segments or write requests with
> > >> 128 segments. I haven't been able to get larger requests, even when
> > >> setting this to 512 or higer.
> > >
> > > What are you using to drive the requests? 'fio'?
> >
> > Yes, I've tried fio with several "bs=" values, but it doesn't seem to
> > change the size of the underlying requests. Have you been able to get
> > bigger requests?
>
> Martin, Jens,
> Any way to drive more than 128 segments?
If the driver is bio based, then there's a natural size constraint on
the number of vecs in the bio. So to get truly large requests, the
driver would need to merge incoming sequential IOs (similar to how it's
done for rq based drivers).
--
Jens Axboe
next prev parent reply other threads:[~2013-04-18 12:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 11:10 [PATCH v1 0/7] xen-block: indirect descriptors Roger Pau Monne
2013-03-27 11:10 ` [PATCH v1 1/7] xen-blkback: print stats about persistent grants Roger Pau Monne
2013-04-09 14:47 ` Konrad Rzeszutek Wilk
2013-03-27 11:10 ` [PATCH v1 2/7] xen-blkback: use balloon pages for all mappings Roger Pau Monne
2013-04-09 14:47 ` Konrad Rzeszutek Wilk
2013-04-15 8:05 ` Roger Pau Monné
2013-04-15 8:12 ` [Xen-devel] " Roger Pau Monné
2013-04-17 14:00 ` Konrad Rzeszutek Wilk
2013-04-15 9:14 ` Roger Pau Monné
2013-04-17 14:05 ` Konrad Rzeszutek Wilk
2013-04-09 15:46 ` Konrad Rzeszutek Wilk
2013-04-15 8:21 ` Roger Pau Monné
2013-03-27 11:10 ` [PATCH v1 3/7] xen-blkback: implement LRU mechanism for persistent grants Roger Pau Monne
2013-04-09 15:42 ` Konrad Rzeszutek Wilk
2013-04-15 11:19 ` Roger Pau Monné
2013-04-17 14:15 ` Konrad Rzeszutek Wilk
2013-03-27 11:10 ` [PATCH v1 4/7] xen-blkback: move pending handles list from blkbk to pending_req Roger Pau Monne
2013-03-27 11:10 ` [PATCH v1 5/7] xen-blkback: make the queue of free requests per backend Roger Pau Monne
2013-04-09 16:13 ` Konrad Rzeszutek Wilk
2013-04-15 13:50 ` Roger Pau Monné
2013-04-17 14:16 ` Konrad Rzeszutek Wilk
2013-03-27 11:10 ` [PATCH v1 6/7] xen-blkback: expand map/unmap functions Roger Pau Monne
2013-03-27 11:10 ` [PATCH v1 7/7] xen-block: implement indirect descriptors Roger Pau Monne
2013-04-09 18:49 ` Konrad Rzeszutek Wilk
2013-04-15 17:01 ` Roger Pau Monné
2013-04-17 14:25 ` Konrad Rzeszutek Wilk
2013-04-17 17:04 ` Roger Pau Monné
2013-04-17 17:27 ` Konrad Rzeszutek Wilk
2013-04-18 12:43 ` Jens Axboe [this message]
2013-04-18 14:16 ` Roger Pau Monné
2013-04-18 14:26 ` Jens Axboe
2013-04-18 15:14 ` Roger Pau Monné
2013-04-18 15:58 ` 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=20130418124355.GW4816@kernel.dk \
--to=axboe@kernel.dk \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.peterson@oracle.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.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