From patchwork Thu Aug 17 19:32:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 9907013 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6F36460386 for ; Thu, 17 Aug 2017 19:32:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5F21E28B94 for ; Thu, 17 Aug 2017 19:32:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 53A8328B98; Thu, 17 Aug 2017 19:32:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CB5C128B94 for ; Thu, 17 Aug 2017 19:32:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752820AbdHQTcX (ORCPT ); Thu, 17 Aug 2017 15:32:23 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:37303 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752632AbdHQTcX (ORCPT ); Thu, 17 Aug 2017 15:32:23 -0400 Received: by mail-io0-f169.google.com with SMTP id c74so26390406iod.4 for ; Thu, 17 Aug 2017 12:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=MgFuaZuvvoDwVOcKT1NrgNJ4vqa7u5SHJ1ZFdwh3F2E=; b=uZooxSMOFgTVRkOija8cTtSS4EkgmMYBRAQrYM7lGbdM7bRzBgU+I9MZbDqgOKO+hn /ooi/S1Ptw30iqnFxqaPXc+Gb1GFIlTVWYrEjPkeKPNE5iZDJSZhEwTpFX+RHKdsWhvD 8aCyt5nByhNc5DiVCAt51MhY1ddojuDZe0ve+aPdLfxpZZWYbdb9gVhOUoOEHE+Kt7ma hauAsuGytLKF4v4L83oe8JVlyXcRKPEskxsZ2LOuF2hbE7Iv3yWoVOos89tLNghzAEtu YwwOKooBwxwfPbiCQ3Zyn2vXhuvqo3unngshjqZnpxdqQ7xbyBl8XrYUiLwkuW1PHcx8 nuFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=MgFuaZuvvoDwVOcKT1NrgNJ4vqa7u5SHJ1ZFdwh3F2E=; b=tG47asffiBjjwEv8VjD/u80c7GtS5MkVBK1S6bZau8+U/K2oW9hhvokTdNI2sH9psG /RJwNwk47RlazfqnCWyvkyFOIzjGGC0TnHAlu0Ah9+eVANsL5W2Sw3SPqMsLiyZOtOyY Kd0CXpH0EYMV26kd7KexbOrS+9y9nugpJ7mXK8OpXc0ZSE0eVNhB8rBWUgINL03wCDvq 0IXSFuY3EdrxDL2eVRDeGXTsqDw6EybFRbKTS3iDCbCNMheXSaqj+DjqT6fos96qVnOM kdWvN9kIcqyQ278XlGzyiDd0Q+fd3PONVdJEN2paPTUgxiOYOJhTgnTiCh5fuZJK+Uar tD1w== X-Gm-Message-State: AHYfb5jsCP+pZX/6GuD5p5e35Pcw3oFXB/7zeP4DxI0QaptSjdxgxGNj tvLJPsTHpqmFmG18 X-Received: by 10.107.132.223 with SMTP id o92mr6105658ioi.105.1502998342470; Thu, 17 Aug 2017 12:32:22 -0700 (PDT) Received: from [192.168.1.154] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id q90sm1778165ioi.41.2017.08.17.12.32.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 12:32:21 -0700 (PDT) To: "linux-nvme@lists.infradead.org" Cc: "linux-block@vger.kernel.org" , Keith Busch , Christoph Hellwig From: Jens Axboe Subject: [RFC PATCH] nvme: always return IRQ_HANDLED Message-ID: <06b85884-efb4-e419-4b31-3aa4751bb338@kernel.dk> Date: Thu, 17 Aug 2017 13:32:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Language: en-US Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We currently have an issue with nvme when polling is used. Just ran some testing on 4.13-rc5, and it's trivial to trigger an IRQ disable ala: [ 52.412851] irq 77: nobody cared (try booting with the "irqpoll" option) [ 52.415310] irq 70: nobody cared (try booting with the "irqpoll" option) when running a few processes polling. The reason is pretty obvious - if we're effective at polling, the triggered IRQ will never find any events. If this happens enough times in a row, the kernel disables our IRQ since we keep returning IRQ_NONE. Question is, what's the best way to solve this. Ideally we should not be triggering an IRQ at all, but that's still not in mainline. Can we safely just return IRQ_HANDLED always? That should work except for the case where we happen to run into an IRQ flood where DO want to turn off the nvme irq. For now, I think that's small price to pay, since the current issue is much worse and leaves the device in a weird non-working state where some queue interrupts are turned off. Signed-off-by: Jens Axboe diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 74a124a06264..21a35faff86f 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -160,7 +160,6 @@ struct nvme_queue { u16 cq_head; u16 qid; u8 cq_phase; - u8 cqe_seen; u32 *dbbuf_sq_db; u32 *dbbuf_cq_db; u32 *dbbuf_sq_ei; @@ -830,22 +829,19 @@ static void nvme_process_cq(struct nvme_queue *nvmeq) consumed++; } - if (consumed) { + if (consumed) nvme_ring_cq_doorbell(nvmeq); - nvmeq->cqe_seen = 1; - } } static irqreturn_t nvme_irq(int irq, void *data) { - irqreturn_t result; struct nvme_queue *nvmeq = data; + spin_lock(&nvmeq->q_lock); nvme_process_cq(nvmeq); - result = nvmeq->cqe_seen ? IRQ_HANDLED : IRQ_NONE; - nvmeq->cqe_seen = 0; spin_unlock(&nvmeq->q_lock); - return result; + + return IRQ_HANDLED; } static irqreturn_t nvme_irq_check(int irq, void *data)