From patchwork Thu Jun 28 15:46:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10494377 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 2CF8A60325 for ; Thu, 28 Jun 2018 15:47:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1733D2A6A8 for ; Thu, 28 Jun 2018 15:47:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0B7E92A6B2; Thu, 28 Jun 2018 15:47:07 +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=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MAILING_LIST_MULTI, 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 DEC252A6A8 for ; Thu, 28 Jun 2018 15:47:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753471AbeF1PrD (ORCPT ); Thu, 28 Jun 2018 11:47:03 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:34649 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753160AbeF1Pqz (ORCPT ); Thu, 28 Jun 2018 11:46:55 -0400 Received: by mail-it0-f43.google.com with SMTP id y127-v6so21872578itd.1 for ; Thu, 28 Jun 2018 08:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=VSeQtSo8/O+mBRSibVNwFlrsQMCbYmViK3cg7lvYDrE=; b=m8dr3pn9rFE4uX7S/QO1wG6WneMJlkAywbECwkowXJgpt8jkZ6HyB9svvuJPnEuJMx rrr59kyaIzyOCcraOkyXJWq+9MvVMT3WnaL7blQgcdrbrzCt0vtX681a8peGdc9EqRB1 xD86DVZJnJVqSpq2Z0f28mG5qSxd1t+I/pP6YoU9gi2fvhZdiHC/J603FyR5QQC+jwYG /lrNFOqCK6rnNa7BvjI2hbN+2Yxl/a3uQmdqFrsTatjVKl4ZgmlFkFbyrZdqITMTPQyS ASy/+ciu1M0QC5Fp5rJEc2H6+FgRaC46l+m1KTAtYw0P8HXvXScikJ5qRdDMZB5HG+Pb I4Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=VSeQtSo8/O+mBRSibVNwFlrsQMCbYmViK3cg7lvYDrE=; b=LTf/Q6130qI5lKrB3TgTE4yYIyUsWHAeminRWNuenPL/gLiNRHHOXZ3hhkrq6rXTBJ c+nhuhaUB23LsDbv2w1ckIYB2c1IygEIHs2jRG5JEpgCwgIi3FivCH128kCFcG8AaSjk EGrwhUT+DoSXq0SHRcSadUpQuSmeHNdDHXmsA25OE94PDUy7+onVXYHLQPZKjjEel6dL 7CeuYV01ADmukqkluPw473h/f0cM2Etw0aVPr2m4uWapjpA1oHS9vHPitcjyi3WUKGhJ P61H4Es0TvNMZT7eaIW8xUUJSgOO7fIk5l8aFebx0ADdBP3mK82rRdfLX8Bpmx8o/yd5 aBfw== X-Gm-Message-State: APt69E02WfiK1VeIq2pDcF0RRCoapncUbjxmQmvE3Atd8WHgqU8nQAzC 3beNVaTj2rWqw7Kfl3fVpyBQ1WZhciY= X-Google-Smtp-Source: AAOMgpeZjuNiw1MPaz1BVMJv27VpF5QhjAoj7ndwbUWx+AFgepZB0of9vWEu1WF+ZT20XmBM3ib/GQ== X-Received: by 2002:a02:3b2d:: with SMTP id c45-v6mr9509492jaa.29.1530200813188; Thu, 28 Jun 2018 08:46:53 -0700 (PDT) Received: from [192.168.1.212] (107.191.0.158.static.utbb.net. [107.191.0.158]) by smtp.gmail.com with ESMTPSA id w7-v6sm3891337ita.34.2018.06.28.08.46.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 08:46:52 -0700 (PDT) To: "linux-block@vger.kernel.org" From: Jens Axboe Subject: [PATCH] blk-mq: don't queue more if we get a busy return Message-ID: <2167f1fb-68b0-c302-88d9-964be5fe3bb3@kernel.dk> Date: Thu, 28 Jun 2018 09:46:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 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 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. Signed-off-by: Jens Axboe Reviewed-by: Omar Sandoval Reviewed-by: Ming Lei diff --git a/block/blk-mq.c b/block/blk-mq.c index b6888ff556cf..d394cdd8d8c6 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1075,6 +1075,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) { @@ -1205,8 +1208,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; }