Received: by 10.223.185.116 with SMTP id b49csp2917797wrg; Mon, 12 Feb 2018 17:53:17 -0800 (PST) X-Google-Smtp-Source: AH8x226+6rZYi9hBxBmFWpx2TTLD/1A8hSkpWzxh2IPbLcPO1S7QvBcxmMc8s739336Zt1frFs6G X-Received: by 2002:a17:902:96a:: with SMTP id 97-v6mr1462587plm.183.1518486797045; Mon, 12 Feb 2018 17:53:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518486797; cv=none; d=google.com; s=arc-20160816; b=fMoC5kRqgzQt6imzM1yzoalLJx04tulcA6yhUK1JHs3rDseiEA0XDL8zZ44Q/D3TuI K9BfqGyDbNS7i3G8UOaVZH82ytM5WtqRAxCSyXBor1I0oH8ThDytpuYfTH73shniJOgX N5aj4AkfMLU8SC5as2ICdUohD7bGWsRdczmENO/Q8ykEQhtvslGsOwWdX+miuzyc/vYz uqs0p2aQdtECMcYQMNm6KyDlHrsrnjkxb2eNhLv/v4m3WBAaHxMgTG+uFY8Ah25s6RhD pr11NL/mUul3zOHTgXXs9jig3jVm+QIHe8GItA/giTg+Thllp/jB2B6L3P/qcr88/+gy PrLA== 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 :arc-authentication-results; bh=WA9uN3VkMCOYqz+Wl0tX69o9KJ0bm/ar3HJIGF422X4=; b=u6qdhpyFCAv1tSDTLmRblczQCWO+FwM7tWOKqmuF8Qry4bo9CjKcZfulKgmEDZTK8P Zqw7vusV22T5V1gLZRZEY/9PnroMKZZ/RkVD+jL4NyH0qMew1JRSj78NvwY90FeRpVi1 4squJIP25FU8J8sbKI9PSE7XU6rVK7HDVwUYJBUvEiqec66Y0k9gYF0ujEY/jVwnlXeo Qsrvshf81sV+Buaz88vRnqzGIV6pGViKXRjgXjW2AE4UU1vwhUADkUnKugp0WifKL7d8 HxeB85HdZr37ClsPw5Y5feOpp2+Vu1Y74BP2JqPgRR4zDxwgde+Gv68AFEpzzzmxqvdv jVng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=A0BvRr55; 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 b14si442209pfk.163.2018.02.12.17.53.02; Mon, 12 Feb 2018 17:53:17 -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-2017-10-26 header.b=A0BvRr55; 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 S933293AbeBMBvo (ORCPT + 99 others); Mon, 12 Feb 2018 20:51:44 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:34968 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933102AbeBMBvn (ORCPT ); Mon, 12 Feb 2018 20:51:43 -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 w1D1ksZn126137; Tue, 13 Feb 2018 01:51:21 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-2017-10-26; bh=WA9uN3VkMCOYqz+Wl0tX69o9KJ0bm/ar3HJIGF422X4=; b=A0BvRr55qXCl9+spf7Uig1xNgYt3cUzKKdFll+OKFP5dGM9kkB890WpXy5QytxzwqG+R Vtw19xPt0fqEHFTbrWUIRc3mzA8CEoVVVWBonzHv9eQrHnIRYczLbh/XjsqQgqcjw5Ow I9MbooOmlzTug3+90ENL3gaqCbrlrpEUm+Re8lO2dseKBbenngAAjOp/oFMSUuQifRHg l2vYSgxnQbyGtxi8KTQ+y0DyXSfAqJR1dtz/eoOuXw3m35u1Bp8m8X/dhQL3PRAXd/zn 9Q0vXqnTBEeYVMeIulPk6m4nmwlFn/f1yXdKyHAM75DG13dwMeD6/Q3Sh6TmwaWuEeag lA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2g3p4b83ev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Feb 2018 01:51:21 +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 w1D1pKAi011472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Feb 2018 01:51:20 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w1D1pJGP014673; Tue, 13 Feb 2018 01:51:19 GMT Received: from [10.182.69.179] (/10.182.69.179) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Feb 2018 17:51:19 -0800 Subject: Re: [PATCH] nvme-pci: drain the entered requests after ctrl is shutdown To: Keith Busch , Sagi Grimberg Cc: axboe@fb.com, linux-nvme@lists.infradead.org, hch@lst.de, linux-kernel@vger.kernel.org References: <1518440222-652-1-git-send-email-jianchao.w.wang@oracle.com> <20180212191519.GD16255@localhost.localdomain> From: "jianchao.wang" Message-ID: <23035bb1-3548-34ba-4d38-3977b0bbbb8b@oracle.com> Date: Tue, 13 Feb 2018 09:51:26 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180212191519.GD16255@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8803 signatures=668668 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=989 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802130019 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Keith andn Sagi Thanks for your kindly response and comment on this. On 02/13/2018 03:15 AM, Keith Busch wrote: > On Mon, Feb 12, 2018 at 08:43:58PM +0200, Sagi Grimberg wrote: >> >>> Currently, we will unquiesce the queues after the controller is >>> shutdown to avoid residual requests to be stuck. In fact, we can >>> do it more cleanly, just wait freeze and drain the queue in >>> nvme_dev_disable and finally leave the queues quiesced. >> >> Does this fix a bug? What is the benefit of leaving the queues >> quiesced in shutdown? > > This doesn't appear to fix anything. The things this patch does do are > either unnecessary (quiece), or already done elsewhere (wait freeze). > Yes, this patch doesn't fix any bug. Since we will let the request to be drained for shutdown case to avoid to be stuck, why not do it in nvme_dev_disable and then quiesce the queue again. In nvme_dev_disable, we unquiesce the queues finally, it looks really something odd. And always give me a feeling that something is still ongoing and not completed....It looks like something is leaking.... ;) Why not we complete it in nvme_dev_disable ? Thanks Jianchao