Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp78437imu; Thu, 6 Dec 2018 19:42:43 -0800 (PST) X-Google-Smtp-Source: AFSGD/UMCml/Yy3H7oIfaG4JjPdjmCiWt8be8VWyBai1G3NMmA/Lko1aPbkCRiMEOdQ4Jq8Dv1uU X-Received: by 2002:a17:902:47aa:: with SMTP id r39mr612949pld.219.1544154163336; Thu, 06 Dec 2018 19:42:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544154163; cv=none; d=google.com; s=arc-20160816; b=PYtQsSx8lNhVF2b7Qub9n8PpEtaQ2ugjQmDumcLlaUwztIkUH66fIyJSWtJmRg3fL7 h1v48YUua/CYOGPZGzMpwAttFV2tqaY2D0M6kXl0LlOEmSi16uCjYAsKUBn0NpGIdnqX 0BMfoG92zUvSbeO35xP0RcD7uiY02Z2JZV2f+4jhhFl2co6Z8QE5njWjpkUgDfECQd/x hOHNv23SDz9S2g+1bP5++dpFc8GGSrG1GaiO0BscJj7fC3Poec1MFHcc+L39dqwKPeS0 U1yIyvh8gQB2h30jjrWABHGcEHrmyD/zRQuhK8u09y+5dcH6RH9SJjLfieCcdolLYejX Yjsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=DLI19823PeHQbHOd2QGKV3oKnPuIvGVvEoqUqIW5NjM=; b=SEkbdtWN8ZxyIAp2LoTfIkfRuO7AMB/IkBY3WVmFKhcUKqBe84yeFvknOIxtSVktwD zh+wXFXz7y8uyRX+Gy9wyOc83GunIhH7K83whhZTfEv9U4T+Ixq/l1eoe/JmYzT8W1JA +Sk5VPNa4fkJ89hOMegoaBz0eJt44dtXRBxmbYmmT3xiAkwJWvQigPLDbTr/DYbgAzKY 1HhmZlD1tGRObw8jYai/Pwgko8tytYtLkCxAdw7Y2ecE+huR7gqttKER1ihl59yYSse+ 7yqnUvBeuxNsP6Qh4BFadjsyhXXNJ2p45GqgP8c1Zzoujef/wCQic2MbSA56JRaFITyM LGzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b="2I/wJMsQ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8si1864868plk.9.2018.12.06.19.42.24; Thu, 06 Dec 2018 19:42:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b="2I/wJMsQ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726029AbeLGDlT (ORCPT + 99 others); Thu, 6 Dec 2018 22:41:19 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:59572 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725967AbeLGDlS (ORCPT ); Thu, 6 Dec 2018 22:41:18 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB73dSxS008257; Fri, 7 Dec 2018 03:41:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=DLI19823PeHQbHOd2QGKV3oKnPuIvGVvEoqUqIW5NjM=; b=2I/wJMsQ1pGVw55zHpxRf5LEIGchZGvbl8X0mfFtQOZrFXEig3h6LbFG1xibppFOiuve HR7vbj8v2QMQAbOOpnKdCOPhcJMpIulGgyj6LvJBFR9kN+PYowozK2EsvA98Tx/uLBIu 4oGoFukWZQ18N2GKk+LZmfI7tZ9wkV2ysQLIkhpEYYNlHgIy1KJFGewUFIYihtVkcWrO TQY5dQhBXCF+qJKPz6h4E9NBLZ5Skgai6Je9WuHknlQtJThuFuYYqTabgcS48gMD446I R5wB4EvprvcbPKh+bJcuE13e8IWqD2zi48LJ2PHK5rxKPxvhmYdQ+lUV/OCyNkgjrhcQ Dw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2p3jxrujap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Dec 2018 03:41:14 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wB73fENs013931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Dec 2018 03:41:14 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wB73fDxd012516; Fri, 7 Dec 2018 03:41:13 GMT Received: from [10.182.69.118] (/10.182.69.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Dec 2018 19:41:13 -0800 Subject: Re: [PATCH V11 0/4] blk-mq: refactor code of issue directly To: Jens Axboe Cc: ming.lei@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org References: <1544152185-32667-1-git-send-email-jianchao.w.wang@oracle.com> <0adf3419-bcce-93d8-51fb-aee7cbb5ae17@oracle.com> <16205e68-aa5e-c59d-364e-4164a0e51dc7@kernel.dk> From: "jianchao.wang" Message-ID: Date: Fri, 7 Dec 2018 11:41:56 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9099 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812070029 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/7/18 11:34 AM, Jens Axboe wrote: > On 12/6/18 8:32 PM, Jens Axboe wrote: >> On 12/6/18 8:26 PM, jianchao.wang wrote: >>> >>> >>> On 12/7/18 11:16 AM, Jens Axboe wrote: >>>> On 12/6/18 8:09 PM, Jianchao Wang wrote: >>>>> Hi Jens >>>>> >>>>> Please consider this patchset for 4.21. >>>>> >>>>> It refactors the code of issue request directly to unify the interface >>>>> and make the code clearer and more readable. >>>>> >>>>> This patch set is rebased on the recent for-4.21/block and add the 1st >>>>> patch which inserts the non-read-write request to hctx dispatch >>>>> list to avoid to involve merge and io scheduler when bypass_insert >>>>> is true, otherwise, inserting is ignored, BLK_STS_RESOURCE is returned >>>>> and the caller will fail forever. >>>>> >>>>> The 2nd patch refactors the code of issue request directly to unify the >>>>> helper interface which could handle all the cases. >>>>> >>>>> The 3rd patch make blk_mq_sched_insert_requests issue requests directly >>>>> with 'bypass' false, then it needn't to handle the non-issued requests >>>>> any more. >>>>> >>>>> The 4th patch replace and kill the blk_mq_request_issue_directly. >>>> >>>> Sorry to keep iterating on this, but let's default to inserting to >>>> the dispatch list if we ever see busy from a direct dispatch. I'm fine >>>> with doing that for 4.21, as suggested by Ming, I just didn't want to >>>> fiddle with it for 4.20. This will prevent any merging on the request >>>> going forward, which I think is a much safer default. >>>> >>>> You do this already for some cases. Let's do it unconditionally for >>>> a request that was ever subjected to ->queue_rq() and we didn't either >>>> error or finish after the fact. >>>> >>> I have done it in this version if I get your point correctly. >>> Please refer to the following fragment in the 2nd patch. >>> >>> + /* >>> + * If the request is issued unsuccessfully with >>> + * BLK_STS_DEV_RESOURCE or BLK_STS_RESOURCE, insert >>> + * the request to hctx dispatch list due to attached >>> + * lldd resource. >>> + */ >>> + force = true; >>> + ret = __blk_mq_issue_directly(hctx, rq, cookie, last); >>> +out_unlock: >>> + hctx_unlock(hctx, srcu_idx); >>> +out: >>> + switch (ret) { >>> + case BLK_STS_OK: >>> + break; >>> + case BLK_STS_DEV_RESOURCE: >>> + case BLK_STS_RESOURCE: >>> + if (force) { >>> + blk_mq_request_bypass_insert(rq, run_queue); >>> + ret = bypass ? BLK_STS_OK : ret; >>> + } else if (!bypass) { >>> + blk_mq_sched_insert_request(rq, false, >>> + run_queue, false); >>> + } >>> + break; >>> + default: >> >> You are right, I missed that you set force = true before doing the >> issue. So this looks good to me! > > I applied your series. With this, we should be good to remove the > REQ_NOMERGE logic that was added for the corruption case, and the > blk_rq_can_direct_dispatch() as well? > Yes, it should be that. Every thing rejected by .queue_rq is ended or inserted into hctx dispatch list. And also direct-issue path is unified with normal path. Thanks Jianchao