From: Rusty Russell <rusty@rustcorp.com.au>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
Date: Thu, 20 May 2010 14:31:50 +0930 [thread overview]
Message-ID: <201005201431.51142.rusty@rustcorp.com.au> (raw)
In-Reply-To: <4BF39C12.7090407@redhat.com>
On Wed, 19 May 2010 05:36:42 pm Avi Kivity wrote:
> > Note that this is a exclusive->shared->exclusive bounce only, too.
> >
>
> A bounce is a bounce.
I tried to measure this to show that you were wrong, but I was only able
to show that you're right. How annoying. Test code below.
> Virtio is already way too bouncy due to the indirection between the
> avail/used rings and the descriptor pool.
I tried to do a more careful analysis below, and I think this is an
overstatement.
> A device with out of order
> completion (like virtio-blk) will quickly randomize the unused
> descriptor indexes, so every descriptor fetch will require a bounce.
>
> In contrast, if the rings hold the descriptors themselves instead of
> pointers, we bounce (sizeof(descriptor)/cache_line_size) cache lines for
> every descriptor, amortized.
We already have indirect, this would be a logical next step. So let's
think about it. The avail ring would contain 64 bit values, the used ring
would contain indexes into the avail ring.
So client writes descriptor page and adds to avail ring, then writes to
index. Server reads index, avail ring, descriptor page (3). Writes used
entry (1). Updates last_used (1). Client reads used (1), derefs avail (1),
updates last_used (1), cleans descriptor page (1).
That's 9 cacheline transfers, worst case. Best case of a half-full ring
in steady state, assuming 128-byte cache lines, the avail ring costs are
1/16, the used entry is 1/64. This drops it to 6 and 9/64 transfers.
(Note, the current scheme adds 2 more cacheline transfers, for the descriptor
table, worst case. Assuming indirect, we get 2/8 xfer best case. Either way,
it's not the main source of cacheline xfers).
Can we do better? The obvious idea is to try to get rid of last_used and
used, and use the ring itself. We would use an invalid entry to mark the
head of the ring.
Any other thoughts?
Rusty.
next prev parent reply other threads:[~2010-05-20 5:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 20:58 [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself Michael S. Tsirkin
2010-05-05 21:18 ` [Qemu-devel] " Dor Laor
2010-05-06 2:31 ` Rusty Russell
2010-05-06 6:19 ` Michael S. Tsirkin
2010-05-07 3:33 ` Rusty Russell
2010-05-09 21:06 ` Michael S. Tsirkin
2010-05-06 10:00 ` [Qemu-devel] " Avi Kivity
2010-05-07 3:23 ` Rusty Russell
2010-05-11 19:27 ` Avi Kivity
2010-05-11 19:52 ` Michael S. Tsirkin
2010-05-19 7:39 ` Rusty Russell
2010-05-19 8:06 ` Avi Kivity
2010-05-19 22:33 ` Michael S. Tsirkin
2010-05-20 6:04 ` Avi Kivity
2010-05-20 5:01 ` Rusty Russell [this message]
2010-05-20 5:08 ` Rusty Russell
2010-05-23 15:31 ` Michael S. Tsirkin
2010-05-23 15:41 ` Avi Kivity
2010-05-23 15:51 ` Michael S. Tsirkin
2010-05-23 16:03 ` Avi Kivity
2010-05-23 16:30 ` Michael S. Tsirkin
2010-05-24 6:37 ` Avi Kivity
2010-05-24 8:05 ` Michael S. Tsirkin
2010-05-24 11:00 ` Avi Kivity
2010-05-23 17:28 ` Michael S. Tsirkin
2010-05-23 15:56 ` Michael S. Tsirkin
2010-05-20 7:00 ` Avi Kivity
2010-05-20 14:34 ` Rusty Russell
2010-05-20 15:46 ` Avi Kivity
2010-05-20 10:04 ` Michael S. Tsirkin
2010-05-11 18:46 ` [Qemu-devel] " Ryan Harper
2010-05-11 19:48 ` Michael S. Tsirkin
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=201005201431.51142.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtualization@lists.linux-foundation.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).