| Message ID | 20210303115740.127001-10-jefflexu@linux.alibaba.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Mike Snitzer |
| Headers | show |
| Series | dm: support polling | expand |
On Wed, Mar 03 2021 at 6:57am -0500, Jeffle Xu <jefflexu@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@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 > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
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);
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@linux.alibaba.com> --- drivers/nvme/host/pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)