When client has multiple threads that issue io requests
all the time, and the server has a very good performance,
it may cause cpu is running in the irq context for a long
time because it can check virtqueue has buf in the *while*
loop.

So we should keep chan->lock in the whole loop.

Signed-off-by: Yiwen Jiang <jiangyi...@huawei.com>
---
 net/9p/trans_virtio.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 05006cb..e5fea8b 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -148,20 +148,15 @@ static void req_done(struct virtqueue *vq)

        p9_debug(P9_DEBUG_TRANS, ": request done\n");

-       while (1) {
-               spin_lock_irqsave(&chan->lock, flags);
-               req = virtqueue_get_buf(chan->vq, &len);
-               if (req == NULL) {
-                       spin_unlock_irqrestore(&chan->lock, flags);
-                       break;
-               }
-               chan->ring_bufs_avail = 1;
-               spin_unlock_irqrestore(&chan->lock, flags);
-               /* Wakeup if anyone waiting for VirtIO ring space. */
-               wake_up(chan->vc_wq);
+       spin_lock_irqsave(&chan->lock, flags);
+       while ((req = virtqueue_get_buf(chan->vq, &len)) != NULL) {
                if (len)
                        p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
        }
+       chan->ring_bufs_avail = 1;
+       spin_unlock_irqrestore(&chan->lock, flags);
+       /* Wakeup if anyone waiting for VirtIO ring space. */
+       wake_up(chan->vc_wq);
 }

 /**
-- 
1.8.3.1

Reply via email to