On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
> 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 <[email protected]>
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)
And users can
r = virtqueue_kick_prepare(vq);
spin_unlock_irqrestore(...);
if (r)
virtqueue_kick_notify(struct virtqueue *vq)
--
MST
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
