[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210524145928.GA3873@lst.de>
Date: Mon, 24 May 2021 16:59:28 +0200
From: Christoph Hellwig <hch@....de>
To: Stefan Hajnoczi <stefanha@...hat.com>
Cc: virtualization@...ts.linux-foundation.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@....de>,
Jason Wang <jasowang@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Jens Axboe <axboe@...nel.dk>, slp@...hat.com,
sgarzare@...hat.com, "Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH 3/3] virtio_blk: implement blk_mq_ops->poll()
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?
Powered by blists - more mailing lists