[dm-devel] [PATCH v5 09/12] nvme/pci: don't wait for locked polling queue
Mike Snitzer
snitzer at redhat.com
Wed Mar 10 21:57:27 UTC 2021
On Wed, Mar 03 2021 at 6:57am -0500,
Jeffle Xu <jefflexu at linux.alibaba.com> wrote:
> There's no sense waiting for the hw queue when it currently has been
> locked by another polling instance. The polling instance currently
> occupying the hw queue will help reap the completion events.
>
> It shall be safe to surrender the hw queue, as long as we could reapply
> for polling later. For Synchronous polling, blk_poll() will reapply for
> polling, since @spin is always True in this case. While For asynchronous
> polling, i.e. io_uring itself will reapply for polling when the previous
> polling returns 0.
>
> Besides, it shall do no harm to the polling performance of mq devices.
>
> Signed-off-by: Jeffle Xu <jefflexu at linux.alibaba.com>
You should probably just send this to the linux-nvme list independent of
this patchset.
Mike
> ---
> drivers/nvme/host/pci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 38b0d694dfc9..150e56ed6d15 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1106,7 +1106,9 @@ static int nvme_poll(struct blk_mq_hw_ctx *hctx)
> if (!nvme_cqe_pending(nvmeq))
> return 0;
>
> - spin_lock(&nvmeq->cq_poll_lock);
> + if (!spin_trylock(&nvmeq->cq_poll_lock))
> + return 0;
> +
> found = nvme_process_cq(nvmeq);
> spin_unlock(&nvmeq->cq_poll_lock);
>
> --
> 2.27.0
>
More information about the dm-devel
mailing list