From patchwork Thu May 24 09:16:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10423219 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 2F7D96019D for ; Thu, 24 May 2018 09:15:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 21BFD292F8 for ; Thu, 24 May 2018 09:15:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 15A4A2934F; Thu, 24 May 2018 09:15:26 +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 99D9E292F8 for ; Thu, 24 May 2018 09:15:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965847AbeEXJPY (ORCPT ); Thu, 24 May 2018 05:15:24 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:51894 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965445AbeEXJPV (ORCPT ); Thu, 24 May 2018 05:15:21 -0400 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 w4O91QdD108779; Thu, 24 May 2018 09:15:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=QESncLy3N/VAop/1jGQhMQQldFAU7Kx2SALh17nxIjs=; b=DniOkbAKZEvHp3A2CYefK3j5BZ0sfRyh318RXYeYDde0DZgVD0Fx1RUmyEmYbwPIUKB1 61U4r7D5ZXqsnaTSslLz96PDTiTipFWjoHxJibYD4eA5ngkLzx9qnREGhdv+/GsGGY4/ JolHK7V6oirPZG0G4Zj9Hq7LklbdemSvY8jrpmxxDso9G13T+FfMvueClhl/35d61UQa pKToJP25ftmKGA1B3OFXAGb6h2Idf4GjaJddtdXbCgW8XsNpuus4M7CDD1lXmZIfhMNP X13oAlekZrUi86ytqLHXOi8yu9dY52LJTbJnjsrYa+0zqhxEMuk9ClrtC0kR58YzTYT8 1A== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2j4nh7fce0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 May 2018 09:15:16 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4O9FFjM012217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 May 2018 09:15:16 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4O9FFiM025641; Thu, 24 May 2018 09:15:15 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.70.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 May 2018 02:15:15 -0700 From: Jianchao Wang To: qla2xxx-upstream@cavium.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] scsi: qla2xxx: reduce the time granularity of the qla2x00_eh_wait_on_command Date: Thu, 24 May 2018 17:16:10 +0800 Message-Id: <1527153370-1741-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=8902 signatures=668700 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=787 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805240111 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If the cmd has not be returned after aborted by qla2x00_eh_abort, when qla2x00_eh_wait_on_command is invoked, it has to wait for it. However, the time is 1000ms at least currently. If there are a lot cmds need to be aborted, the delay could be long enough to lead to panic due to such as hung task, ocfs2 heartbeat, etc, just before scsi recovery work completes and get back the HBA. Change the granularity to 1ms, even though more context switches would be introduced, but it should be ok as it is not hot path. Signed-off-by: Jianchao Wang --- drivers/scsi/qla2xxx/qla_os.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c index 15eaa6d..9ea4e02 100644 --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -1064,7 +1064,7 @@ qla2xxx_mqueuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd, static int qla2x00_eh_wait_on_command(struct scsi_cmnd *cmd) { -#define ABORT_POLLING_PERIOD 1000 +#define ABORT_POLLING_PERIOD 1 #define ABORT_WAIT_ITER ((2 * 1000) / (ABORT_POLLING_PERIOD)) unsigned long wait_iter = ABORT_WAIT_ITER; scsi_qla_host_t *vha = shost_priv(cmd->device->host);