Messages in this thread | | | From | Paolo Bonzini <> | Subject | Re: [PATCH 3/3] virtio_blk: implement blk_mq_ops->poll() | Date | Tue, 25 May 2021 09:22:48 +0200 |
| |
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
| |