From patchwork Tue Mar 14 14:36:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 9623609 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 EB3CC604CC for ; Tue, 14 Mar 2017 14:37:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DB7B528562 for ; Tue, 14 Mar 2017 14:37:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D0454285B9; Tue, 14 Mar 2017 14:37:03 +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.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 1575E28562 for ; Tue, 14 Mar 2017 14:37:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751523AbdCNOhC (ORCPT ); Tue, 14 Mar 2017 10:37:02 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:36799 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbdCNOga (ORCPT ); Tue, 14 Mar 2017 10:36:30 -0400 Received: by mail-io0-f181.google.com with SMTP id l7so483453ioe.3 for ; Tue, 14 Mar 2017 07:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=68pqTfLSWT7NiL912TXNl5AC7/5sM+K0/ij5MSpNjtE=; b=cJMTgeDQyjAzSx+Pb35O3FRo3t2i5TK/p+AObMS00jT8WIKfrZHqtHwcunYZRdITob D63FsGJm+uXDD+X0zL4L/CxxxnShty/Y78BSiekB6STQxwXaEa6FxrQuUmxYlVix81Go E5jynp07uLkKxx3jRUFLpfrjlUbw8sw6Z85A3ErpzO2PRe71RPdA2NMWg9UveyRr1cnL ZdzDvEw80C7bnCVePffnQ528DmP9sZpKAycdy1ccuvhTmeKxJixcP2i/LVRjid5vyH4F /DqNAWb3S4XjaCdIhcVzYIPBOpCXZW3K8q/oy6+6u2umm5bhcqaeWumCI71GAeErGMWp AaCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=68pqTfLSWT7NiL912TXNl5AC7/5sM+K0/ij5MSpNjtE=; b=oR8kw9HPDZfCcXvoeG+SMxvDUfb33V4WDLe5zcHqf113lxefXFuV3fsPaLVeu1sSSm CFJH5Hq57Tngn80eAUAHuKDshKAvrKv6ZSqt5J3WbuU9DE37pbsdkIlcz+9FGUnsglNT TjE/D5oOXVSgFCz2qib74E04ht9k6qbgY47t0UR9VEbKMtRSrxtD5gW6yGMLEoLbJ+bJ OPQ4W9npBaVB1Xyqc6Owit8pRmwnnEahe7l8ULhc0idqwpz1FOFjiCInO946XOcwWOjk XGDE+a4rIBshBXFcE1S9LX+0T2wZW38CFFt4fFA/q4JBKc9ZrR/DO+WZxOHBBRlbJp9I hVcg== X-Gm-Message-State: AFeK/H0TfU4xp9DPICkwC3Px7MK4lnp4hQl2Hd/xGhPJjN3ybjEmdbuRGH+Qwn/DOx2Y9Q== X-Received: by 10.107.136.96 with SMTP id k93mr170156iod.20.1489502188617; Tue, 14 Mar 2017 07:36:28 -0700 (PDT) Received: from [192.168.1.154] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id b25sm29027iod.32.2017.03.14.07.36.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 07:36:27 -0700 (PDT) Subject: Re: [PATCH 06/16] mmc: core: replace waitqueue with worker To: Adrian Hunter , Linus Walleij References: <20170209153403.9730-1-linus.walleij@linaro.org> <20170209153403.9730-7-linus.walleij@linaro.org> <00989e26-cdb9-48d7-2e46-ae6ef66e59a7@intel.com> <3fc89f9f-fbcf-113d-3644-b6c9dae003f0@intel.com> <8f1f3d4c-410c-2632-c776-4ced363bdb0d@kernel.dk> <97f2a4ea-0802-9f23-6ac7-b9d6c6afbfcc@kernel.dk> Cc: "linux-mmc@vger.kernel.org" , Ulf Hansson , Paolo Valente , Chunyan Zhang , Baolin Wang , linux-block@vger.kernel.org, Christoph Hellwig , Arnd Bergmann From: Jens Axboe Message-ID: Date: Tue, 14 Mar 2017 08:36:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: 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 On 03/14/2017 06:59 AM, Adrian Hunter wrote: > On 13/03/17 16:19, Jens Axboe wrote: >> On 03/13/2017 03:25 AM, Adrian Hunter wrote: >>> On 11/03/17 00:05, Jens Axboe wrote: >>>> On 03/10/2017 07:21 AM, Adrian Hunter wrote: >>>>>> Essentially I take out that thread and replace it with this one worker >>>>>> introduced in this very patch. I agree the driver can block in many ways >>>>>> and that is why I need to have it running in process context, and this >>>>>> is what the worker introduced here provides. >>>>> >>>>> The last time I looked at the blk-mq I/O scheduler code, it pulled up to >>>>> qdepth requests from the I/O scheduler and left them on a local list while >>>>> running ->queue_rq(). That means blocking in ->queue_rq() leaves some >>>>> number of requests in limbo (not issued but also not in the I/O scheduler) >>>>> for that time. >>>> >>>> Look again, if we're not handling the requeued dispatches, we pull one >>>> at the time from the scheduler. >>>> >>> >>> That's good :-) >>> >>> Now the next thing ;-) >>> >>> It looks like we either set BLK_MQ_F_BLOCKING and miss the possibility of >>> issuing synchronous requests immediately, or we don't set BLK_MQ_F_BLOCKING >>> in which case we are never allowed to sleep in ->queue_rq(). Is that true? >> >> Only one of those statements is true - if you don't set BLK_MQ_F_BLOCKING, >> then you may never block in your ->queue_rq() function. But if you do set it, >> it does not preclude immediate issue of sync requests. > > I meant it gets put to the workqueue rather than issued in the context of > the submitter. There's one case that doesn't look like it was converted properly, but that's a mistake. The general insert-and-run cases run inline if we can, but the direct-issue needs a fixup, see below. diff --git a/block/blk-mq.c b/block/blk-mq.c index 159187a28d66..4196d6bee92d 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1434,7 +1434,8 @@ static blk_qc_t request_to_qc_t(struct blk_mq_hw_ctx *hctx, struct request *rq) return blk_tag_to_qc_t(rq->internal_tag, hctx->queue_num, true); } -static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie) +static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie, + bool can_block) { struct request_queue *q = rq->q; struct blk_mq_queue_data bd = { @@ -1475,7 +1476,7 @@ static void blk_mq_try_issue_directly(struct request *rq, blk_qc_t *cookie) } insert: - blk_mq_sched_insert_request(rq, false, true, true, false); + blk_mq_sched_insert_request(rq, false, true, false, can_block); } /* @@ -1569,11 +1570,11 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio) if (!(data.hctx->flags & BLK_MQ_F_BLOCKING)) { rcu_read_lock(); - blk_mq_try_issue_directly(old_rq, &cookie); + blk_mq_try_issue_directly(old_rq, &cookie, false); rcu_read_unlock(); } else { srcu_idx = srcu_read_lock(&data.hctx->queue_rq_srcu); - blk_mq_try_issue_directly(old_rq, &cookie); + blk_mq_try_issue_directly(old_rq, &cookie, true); srcu_read_unlock(&data.hctx->queue_rq_srcu, srcu_idx); } goto done;