On Mon, Jun 20, 2011 at 4:27 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > 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. Just an update that benchmarks are being run. Will send out patches and results as soon as they are in. 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
