On Wed, Mar 03 2021 at 6:57am -0500, Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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 >
