On Fri, 02/13 11:38, Paolo Bonzini wrote: > > > On 13/02/2015 11:29, Fam Zheng wrote: > > I think we should avoid duplicate everything on both virtio-blk and > > virtio-scsi, so they will have differences. > > True, but there are also similarities. virtio-blk can also do per-VQ > iothreads > > > Why do you think Per VQ iothread is far away? > > Because per-VQ iothread needs to use either fine-grained locks or, > especially in the format and protocol driver, no locks at all. No locks > at all applies especially to the raw case, where we can more easily > leverage kernel-side locks and thread-local storage. > > Right now the lock is per-AioContext, but even if you made it > BlockBackend-grained lock, the iothreads will just contend on it and > each device won't get better performance than a single iothread. Making > a single backend faster is unfortunately an extremely important case; if > you have multiple backends you can already move them to separate > virtio-scsi controllers or virtio-blk devices. > > We haven't even started thinking how the design should look like, so I > think it's far away. > > > Limiting to 1 thread for the > > whole scsi bus doesn't sound ultimate solution for me. I think it's not > > harder > > than the MMIO safety work we have, and also somehow independent to it. > > I'm not sure it's independent. While the MMIO safety work does not > imply using fine-grained locks, it probably(*) implies using > fine-grained critical sections. Fine-grained critical sections are > probably(**) a subset of the work needed for fine-grained locks or also > for lockless operation. > > (*) probably = couldn't think of a better way > > (**) probably = I haven't even thought about it > > Paolo >
OK, thanks for elaborating. I think for the sake of single IO thread support we already started, the best option now is to go as you suggested - move bdrv_set_aio_context to virtio_scsi_dataplane_start and hotplug callbacks. Could you review patch 1? (And do we want patch 2?) Thanks, Fam
