From patchwork Wed Nov 27 20:18:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1201795 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47NXD41wBCz9sR8; Thu, 28 Nov 2019 07:19:00 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ia3m2-0003CZ-2a; Wed, 27 Nov 2019 20:18:54 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ia3lw-000389-DB for kernel-team@lists.ubuntu.com; Wed, 27 Nov 2019 20:18:48 +0000 Received: from mail-qt1-f197.google.com ([209.85.160.197]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ia3lv-0004U2-GS for kernel-team@lists.ubuntu.com; Wed, 27 Nov 2019 20:18:47 +0000 Received: by mail-qt1-f197.google.com with SMTP id g13so15479515qtq.16 for ; Wed, 27 Nov 2019 12:18:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3cMWGyp0dZwz9ZDcr1rYVlQ7FOPHiUfEYyuNejeEO3w=; b=Q50fUh2i+YF9tQ/nrT8w9ORRagN5puo4Vl16cuXtq1TD65/8zwRCRjAkl4UnT+w2V0 jweFi1j2AwMj+874ax7774ReSrSupxD5AKRT6SfF0x9M0pjjHoUkqCynK8PZg3zWMSxj cpIb8BaWctmtLeufGVeHkirkCgnhkI6gz1Sr0iGR9avpIhE4B1ykRLvoleDzfeYaI5l1 6SiFpwVpNhE3CxzJi2VXga9PKQpMHJcy/4B95XK+Q2fl+1DS7PYfKI7rY/6jNWd7B0KZ 7i4gKwhFcJPMkjf4OC7MJ/MZBoPsJgCsbZhD6cujrmTIqAxZ1dRwacCLQsT6AtAZUBVe cXsw== X-Gm-Message-State: APjAAAUYHzJWdh0rVtNtZigMpiPf/VCeJ+atUV5UHmvg8aJ4KAFZV8QV buMYy6x7+rr6M7hsLsrADClnszH8W/pJ31+WKCr9a47RgYbwpcYOyOHEONd0d9JSL2JxgD0hYER 61GRapNdEPmw/a9IyOttb5rsXsyfESFWHCeZZxRHS X-Received: by 2002:a0c:edb2:: with SMTP id h18mr7018055qvr.36.1574885926239; Wed, 27 Nov 2019 12:18:46 -0800 (PST) X-Google-Smtp-Source: APXvYqzD4T6AdCLEd1dLiNAXxFLSynmeDnX1V2xWXCPQyBwe7luNrvGgCQTsWsm/j2Fsi2HEEmXspw== X-Received: by 2002:a0c:edb2:: with SMTP id h18mr7018026qvr.36.1574885925933; Wed, 27 Nov 2019 12:18:45 -0800 (PST) Received: from gallifrey.lan ([2804:14c:4e6:1bc:4960:b0eb:4714:41f]) by smtp.gmail.com with ESMTPSA id o13sm8284524qto.96.2019.11.27.12.18.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Nov 2019 12:18:45 -0800 (PST) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [xenial:linux-azure][PATCH 10/15] blk-mq: don't queue more if we get a busy return Date: Wed, 27 Nov 2019 17:18:15 -0300 Message-Id: <20191127201820.32174-11-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191127201820.32174-1-marcelo.cerri@canonical.com> References: <20191127201820.32174-1-marcelo.cerri@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Jens Axboe BugLink: https://bugs.launchpad.net/bugs/1848739 Some devices have different queue limits depending on the type of IO. A classic case is SATA NCQ, where some commands can queue, but others cannot. If we have NCQ commands inflight and encounter a non-queueable command, the driver returns busy. Currently we attempt to dispatch more from the scheduler, if we were able to queue some commands. But for the case where we ended up stopping due to BUSY, we should not attempt to retrieve more from the scheduler. If we do, we can get into a situation where we attempt to queue a non-queueable command, get BUSY, then successfully retrieve more commands from that scheduler and queue those. This can repeat forever, starving the non-queuable command indefinitely. Fix this by NOT attempting to pull more commands from the scheduler, if we get a BUSY return. This should also be more optimal in terms of letting requests stay in the scheduler for as long as possible, if we get a BUSY due to the regular out-of-tags condition. Reviewed-by: Omar Sandoval Reviewed-by: Ming Lei Signed-off-by: Jens Axboe (cherry picked from commit 1f57f8d442f8017587eeebd8617913bfc3661d3d) Signed-off-by: Marcelo Henrique Cerri --- block/blk-mq.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index 3145221ca824..913157d52b92 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1120,6 +1120,9 @@ static bool blk_mq_mark_tag_wait(struct blk_mq_hw_ctx **hctx, #define BLK_MQ_RESOURCE_DELAY 3 /* ms units */ +/* + * Returns true if we did some work AND can potentially do more. + */ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, bool got_budget) { @@ -1250,8 +1253,17 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, blk_mq_run_hw_queue(hctx, true); else if (needs_restart && (ret == BLK_STS_RESOURCE)) blk_mq_delay_run_hw_queue(hctx, BLK_MQ_RESOURCE_DELAY); + + return false; } + /* + * If the host/device is unable to accept more work, inform the + * caller of that. + */ + if (ret == BLK_STS_RESOURCE || ret == BLK_STS_DEV_RESOURCE) + return false; + return (queued + errors) != 0; }