From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Chris Wright <chrisw@sous-sol.org>, Jens Axboe <axboe@kernel.dk>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] virtio: support unlocked queue kick
Date: Wed, 02 Nov 2011 13:49:36 +1030 [thread overview]
Message-ID: <87ty6ntdmf.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20111101144045.GA15433@redhat.com>
On Tue, 1 Nov 2011 16:40:45 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Oct 06, 2011 at 11:18:28AM -0200, Michael S. Tsirkin wrote:
> > On Thu, Oct 06, 2011 at 12:15:36PM +1030, Rusty Russell wrote:
> > > On Wed, 05 Oct 2011 15:54:05 -0400, Christoph Hellwig <hch@infradead.org> wrote:
> > > > Split virtqueue_kick to be able to do the actual notification outside the
> > > > lock protecting the virtqueue. This patch was originally done by
> > > An alternative to this is to update the ring on every virtqueue_add_buf.
> > > MST discussed this for virtio_net, and I think it's better in general.
> > >
> > > The only reason that it wasn't written that way originally is that the
> > > barriers make add_buf slightly more expensive.
> >
> > With event index, I'm not sure that's enough to make the kick lockless
> > anymore.
>
> Hmm, any comment on this? These have been benchmarked
> to give a sizeable speedup, so I'm thinking it's better to take
> the patches as is, if someone has the inclination to redo
> the work with an atomic virtqueue_add_buf, that can
> be applied on top.
I thought it was still a WIP?
Since the problem is contention on the lock inside the block layer, the
simplest solution is to have a separate lock to protect the virtqueue.
A bit more work for virtio_blk, but probably in the noise. And it
eliminated the number of gratuitous wakeups a race would cause in the
lockless patch.
Something like this (untested):
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -19,8 +19,12 @@ struct workqueue_struct *virtblk_wq;
struct virtio_blk
{
+ /* Lock for block layer. */
spinlock_t lock;
+ /* Lock for virtqueue (nests inside vblk->lock). */
+ spinlock_t vq_lock;
+
struct virtio_device *vdev;
struct virtqueue *vq;
@@ -62,6 +66,7 @@ static void blk_done(struct virtqueue *v
unsigned long flags;
spin_lock_irqsave(&vblk->lock, flags);
+ spin_lock(&vblk->vq_lock);
while ((vbr = virtqueue_get_buf(vblk->vq, &len)) != NULL) {
int error;
@@ -94,6 +99,7 @@ static void blk_done(struct virtqueue *v
list_del(&vbr->list);
mempool_free(vbr, vblk->pool);
}
+ spin_unlock(&vblk->vq_lock);
/* In case queue is stopped waiting for more buffers. */
blk_start_queue(vblk->disk->queue);
spin_unlock_irqrestore(&vblk->lock, flags);
@@ -171,10 +177,13 @@ static bool do_req(struct request_queue
}
}
+ spin_lock(&vblk->vq_lock);
if (virtqueue_add_buf(vblk->vq, vblk->sg, out, in, vbr) < 0) {
+ spin_unlock(&vblk->vq_lock);
mempool_free(vbr, vblk->pool);
return false;
}
+ spin_unlock(&vblk->vq_lock);
list_add_tail(&vbr->list, &vblk->reqs);
return true;
@@ -199,8 +208,11 @@ static void do_virtblk_request(struct re
issued++;
}
- if (issued)
+ if (issued) {
+ spin_lock(&vblk->vq_lock);
virtqueue_kick(vblk->vq);
+ spin_unlock(&vblk->vq_lock);
+ }
}
/* return id (s/n) string for *disk to *id_str
@@ -384,6 +396,7 @@ static int __devinit virtblk_probe(struc
INIT_LIST_HEAD(&vblk->reqs);
spin_lock_init(&vblk->lock);
+ spin_lock_init(&vblk->vq_lock);
vblk->vdev = vdev;
vblk->sg_elems = sg_elems;
sg_init_table(vblk->sg, vblk->sg_elems);
next prev parent reply other threads:[~2011-11-02 3:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 19:54 [PATCH 0/5] RFC: ->make_request support for virtio-blk Christoph Hellwig
2011-10-05 19:54 ` [PATCH 1/5] block: add bio_map_sg Christoph Hellwig
2011-10-05 22:51 ` Boaz Harrosh
2011-10-06 13:40 ` Christoph Hellwig
2011-10-05 19:54 ` [PATCH 2/5] virtio: support unlocked queue kick Christoph Hellwig
2011-10-06 8:42 ` Stefan Hajnoczi
[not found] ` <87r52qgaf3.fsf@rustcorp.com.au>
2011-10-06 13:19 ` Michael S. Tsirkin
2011-11-01 14:40 ` Michael S. Tsirkin
2011-11-02 3:19 ` Rusty Russell [this message]
2011-11-02 7:25 ` Christoph Hellwig
2011-11-03 4:01 ` Rusty Russell
2011-11-03 5:15 ` Rusty Russell
2011-11-03 6:45 ` Minchan Kim
2011-10-05 19:54 ` [PATCH 3/5] virtio-blk: remove the unused list of pending requests Christoph Hellwig
2011-10-05 19:54 ` [PATCH 4/5] virtio-blk: reimplement the serial attribute without using requests Christoph Hellwig
2011-10-05 19:54 ` [PATCH 5/5] virtio-blk: implement ->make_request Christoph Hellwig
2011-10-06 1:52 ` Rusty Russell
2011-10-06 13:42 ` Christoph Hellwig
2011-10-06 13:53 ` Jens Axboe
2011-10-05 20:31 ` [PATCH 0/5] RFC: ->make_request support for virtio-blk Vivek Goyal
2011-10-05 21:53 ` Christoph Hellwig
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=87ty6ntdmf.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=axboe@kernel.dk \
--cc=chrisw@sous-sol.org \
--cc=hch@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=stefanha@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.