Thread (2 messages) 2 messages, 2 authors, 2011-06-20

Re: [RFC] virtio: Support releasing lock during kick

From: Stefan Hajnoczi <hidden>
Date: 2011-06-20 15:27:18

Possibly related (same subject, not in this thread)

On Sun, Jun 19, 2011 at 8:14 AM, Michael S. Tsirkin [off-list ref] wrote:
On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
quoted
The virtio block device holds a lock during I/O request processing.
Kicking the virtqueue while the lock is held results in long lock hold
times and increases contention for the lock.

This patch modifies virtqueue_kick() to optionally release a lock while
notifying the host.  Virtio block is modified to pass in its lock.  This
allows other vcpus to queue I/O requests during the time spent servicing
the virtqueue notify in the host.

The virtqueue_kick() function is modified to know about locking because
it changes the state of the virtqueue and should execute with the lock
held (it would not be correct for virtio block to release the lock
before calling virtqueue_kick()).

Signed-off-by: Stefan Hajnoczi <redacted>
While the optimization makes sense, the API's pretty hairy IMHO.
Why don't we split the kick functionality instead?
E.g.
       /* Report whether host notification is necessary. */
       bool virtqueue_kick_prepare(struct virtqueue *vq)
       /* Can be done in parallel with add_buf/get_buf */
       void virtqueue_kick_notify(struct virtqueue *vq)
This is a nice idea, it makes the code cleaner.  I am testing patches
that implement this and after Khoa has measured the performance I will
send them out.

Stefan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help