On 24/05/21 16:59, Christoph Hellwig wrote:
On Thu, May 20, 2021 at 03:13:05PM +0100, Stefan Hajnoczi wrote:
Possible drawbacks of this approach:
- Hardware virtio_blk implementations may find virtqueue_disable_cb()
expensive since it requires DMA. If such devices become popular then
the virtio_blk driver could use a similar approach to NVMe when
VIRTIO_F_ACCESS_PLATFORM is detected in the future.
- If a blk_poll() thread is descheduled it not only hurts polling
performance but also delays completion of non-REQ_HIPRI requests on
that virtqueue since vq notifications are disabled.
Yes, I think this is a dangerous configuration. What argument exists
again just using dedicated poll queues?
There isn't an equivalent of the admin queue in virtio-blk, which would
allow the guest to configure the desired number of poll queues. The
number of queues is fixed.
Could the blk_poll() thread use preempt notifiers to enable/disable
callbacks, for example using two new .poll_start and .end_poll callbacks
to struct blk_mq_ops?
Paolo
