On Sun, Jun 19, 2011 at 8:14 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > 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 <stefanha@xxxxxxxxxxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
