Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp68339imu; Thu, 6 Dec 2018 19:26:57 -0800 (PST) X-Google-Smtp-Source: AFSGD/WVya+hW7NU4MvL7xJ/IL7KK5BSpWqD6VyovM1N1KlY1csE/r0G8IGsxmqL90PI8V7SUKJp X-Received: by 2002:a17:902:9691:: with SMTP id n17mr614367plp.9.1544153217333; Thu, 06 Dec 2018 19:26:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544153217; cv=none; d=google.com; s=arc-20160816; b=PVJjxF2Z/M8tg+YoCfwlrSRyGm4Uk4rzaQf5Noo+qNDYyejyaJ413KDP3ylxysboD8 Xdvz6GL83Cjy6brAtbeJjQK/wBpMbDAmS1Ra5qWlJjyWbHlUrCABJy4e0nYFOA9iQXsR 9qj7I/qZf2r74PZASGXr525PEs4yTxRoRWLA19Gb+QwKXeCg0ue5OCB9wn58RLN+8D34 gOv2O5ZNyFUEgixIXo9hO12aPMBtAeKH5pelVcj+Cg2XvwZ9QRrjsUSvye7vYA2NTL1C OoFRKHPV5CwckLpc8l/ZkHSAoTnLU/nuEKHaK++MFsjDAFu3LrX2/3LpcY3EFjxE6zkr 2knQ== 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=HUL2igTSGf2aHg9hhP48aEPvyNhWdZ3qngjeHDvPnCM=; b=liv2HRIgcZwosk/eaW7EEbuAC3odJDTKdDQxHXQrmedyAEwLRwMaAGm0OP8CTypUwQ gokImOxCN1/enN7eACZoT6DYEhj4Y0x1cbYLbw1zXM3HnATzfc5D+S7CfriSpaqTGZVv wsLt48xoTEKxtTSD/KU4+2N5JoAKjtKgJjHMO7pPsKByPHbDWcRg+eWKNqTB5OWqralH 6LaJdxptmOTAj0L+9SOCreHRe+Fykze3Gg6U2LGl8PRa+EBILAaDgYtZpzXbyysyaCp8 wfohkR7gp9N9JwjbKTikl+uZ+7++iJZcExmym4Ezw+bfoNNu0iW8ceu4biyb9z86ELxI OMyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=xiHcJavq; 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 72si1855922plb.224.2018.12.06.19.26.36; Thu, 06 Dec 2018 19:26:57 -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=xiHcJavq; 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 S1725988AbeLGD0A (ORCPT + 99 others); Thu, 6 Dec 2018 22:26:00 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:45714 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbeLGD0A (ORCPT ); Thu, 6 Dec 2018 22:26:00 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB73OUfO001467; Fri, 7 Dec 2018 03:25:55 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=HUL2igTSGf2aHg9hhP48aEPvyNhWdZ3qngjeHDvPnCM=; b=xiHcJavq/aXOdfxeSwXAvU/1MxY/jTa/6JBI0POXM86LKhU/EiYGGrt6RcvP7onw32q/ +sRgdCfSadwJjzC/5QIovbIs9+xmQWSFRiokl1jERmoQ9wqVoQgNd6X5A2gwKfillOik Zmhcko+3UKz7L3AwQMWl+LKLdkFAZnKQ7zdDX3tDMHiCNBnIKn2PRh1fPAgItXmMS3CX R4UVNKUxsUQfBXIee1/1U9kz1lLWvGpKD4Yzle+jXOF0HEL966l3ZE4VqoItTf44RCuM X9GW2FA2bvDuWrvOkpYZbkYc6K7UZWnqL09q15dK/UKh3y1P/43zvyUQdLCF5ilNhcRZ DQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2p3ftffhhq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 07 Dec 2018 03:25:55 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wB73PtQU004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Dec 2018 03:25:55 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB73Pskj016411; Fri, 7 Dec 2018 03:25:54 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:25:54 -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> From: "jianchao.wang" Message-ID: <0adf3419-bcce-93d8-51fb-aee7cbb5ae17@oracle.com> Date: Fri, 7 Dec 2018 11:26:36 +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=659 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812070027 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: Thanks Jianchao