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
> But yes, stop using bdrv_set_aio_context will be the other way to make it
> right, just harder to do.
