From patchwork Wed Oct 17 09:07:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10645131 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D6818109C for ; Wed, 17 Oct 2018 09:05:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CA0E02AC40 for ; Wed, 17 Oct 2018 09:05:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BDCD92AC47; Wed, 17 Oct 2018 09:05:08 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY 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 69CBE2AC40 for ; Wed, 17 Oct 2018 09:05:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726922AbeJQQ7v (ORCPT ); Wed, 17 Oct 2018 12:59:51 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:46468 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726904AbeJQQ7u (ORCPT ); Wed, 17 Oct 2018 12:59:50 -0400 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 w9H8x5Qx068727; Wed, 17 Oct 2018 09:05:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2018-07-02; bh=y7rKbbJdqQCdGCoY1rQMiXNazzJMR6aKmUNiKWKlilc=; b=ZTCdQz62RqBk9evuWTB8Woi9uhBjlw9Zduss5nB5fW5L+eA0l0fy9N5O52iA3tL6R0Q+ ++3EjV2v3O0UhtMpsUQ9s96ZAPVcrkgYZEzgkXTBwJBAKfR9AjJPKJrpPEDx3DQ76bQp avNz+Z5aI285lYRbTkPADm18josUI5um0DGvhyu9kfIl92XerrVx6LDn45NNbj7C14wf UxDwfmvet3+jsjcvRV53FS4Nlri6Zhbc4TqozHeBeEArWfugp1sKHH5KC0+eweNz1jry 7Ua34ibyLxJhU+atUn4TK/Clio+hVNNIbol19FSAty/RzOXuHYzAlmeuCHEjN753+Ko6 /g== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2n39brdgyj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Oct 2018 09:05:01 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9H950Gb013026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Oct 2018 09:05:00 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9H94xAA024720; Wed, 17 Oct 2018 09:05:00 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Oct 2018 02:04:59 -0700 From: Jianchao Wang To: axboe@kernel.dk Cc: hch@lst.de, keith.busch@linux.intel.com, ming.lei@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH V2 0/3] blk-mq: introduce bio retrieve mechanism Date: Wed, 17 Oct 2018 17:07:09 +0800 Message-Id: <1539767232-9389-1-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9048 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=618 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170082 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 Hi Jenss This patchset introduces a new bio retrieve mechanism. It will flush all the requests, take the bios down from them and end them, then submit the bios again later. Then we could avoid: - fail requests on the dying hw queues, this could be fatal for filesystem. - depend on storage device to drain the queue before update hw queues. this could introduce hung into nvme_reset_work. The 1st patch introduce the bio retrieve mechanism The 2nd patch apply the bio retrieve mechanism in updating hw queues The 3rd patch unquiesces the queues after updating hw queues in nvme_reset_work V2: - clear BIO_QUEUE_ENTERED of requeued bios (1/3) - sync bio_requeue_work in blk_cleanup_queue (1/3) - discard the unnecessary synchronize_sched (2/3) - discard the 4th patch which is wrong - some misc comment changes Jianchao Wang(3) blk-mq: introduce bio retrieve mechanism blk-mq: retrieve bios before update nr_hw_queues nvme-pci: unquiesce queues after update hw queues block/blk-core.c | 2 ++ block/blk-mq-sched.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ block/blk-mq.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++- drivers/nvme/host/pci.c | 4 ++-- include/linux/blk-mq.h | 4 ++++ include/linux/blkdev.h | 2 ++ 6 files changed, 144 insertions(+), 3 deletions(-) Thanks Jianchao