Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp239213pxb; Tue, 29 Mar 2022 03:19:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDnrz/QD4HZV81wRjd4xc9suRsu5dTM3GbHbeMvs/b6YAjhX6N1EQfSwwsZeyV6LwJ00rL X-Received: by 2002:aa7:da52:0:b0:418:d8b1:1923 with SMTP id w18-20020aa7da52000000b00418d8b11923mr3554406eds.105.1648549166404; Tue, 29 Mar 2022 03:19:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648549166; cv=none; d=google.com; s=arc-20160816; b=muwoAvUMfX4gTNjAvs2QuYW0FYFmftEosAL5iUuypQVCBqQLVMzCnhXCLZQ0NqLjY+ n/08E6EWaeJXHFGAay0GICa6ok4D9B/RxXLA5x/0q/Q5pQwNKWKfFmOuxNRSlDGSa471 /NOH58G8kiBiRLx6bCF5QWxJ6nqm2ExMbB+8HUDC+7jbQW+Ctd0sp4g5QkSAPIOL0ksl R0LpkIwaztWh8pDOdvAax6Wg+djJxsX6w6eg9dQB6lopnOBDeSPIywwQoX0FnB1zjmNw //+Hcn958xsrsTz4RS25bmbXqG5XHnIHUywndnKCBHdVEyvqK7JUcXaX8nxTMjgB2PUX ldug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:cc:to:subject:from; bh=NhHNNoIVz1DXEJfQTSYbjRLUtDLxOIz7beiS2Hbv1s0=; b=wFuKHRwNjZtPPUgKb73gHiA35dCfZR5rkfc6JZnLM+62nlM0eoOpKBu+zXnWUKEVhI tmZoqBJDTN5KCnnlb5DXTE7gmc6I/unI4IeO05+RH5WAJ3YM0N+uHdRrUJoLzwtIJxIX uu8LCI1AB8CYnHNrv5eb5M7YtcyWgu1GCHuzJ6CB92xFpBJeOVtg8JJqF/0aqfDCNeM+ bEEnSiQDUsRFOoVn5lOYdcHUDxaLOO2ry27vVZlG+XmxlKtc6HB4LhOKh8H4cLiDbPZC B4274s+FMgXjlgNIfoai1in12Zj9HGV06Uj+G1/laOll5yqcTJOebYMoI28WUT6QeV+c 83MQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e7-20020a1709062c0700b006df76385c36si15862832ejh.214.2022.03.29.03.19.00; Tue, 29 Mar 2022 03:19:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234435AbiC2JIR (ORCPT + 99 others); Tue, 29 Mar 2022 05:08:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233938AbiC2JIQ (ORCPT ); Tue, 29 Mar 2022 05:08:16 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 781C0242200; Tue, 29 Mar 2022 02:06:33 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KSNtY40TWzfZVc; Tue, 29 Mar 2022 17:04:53 +0800 (CST) Received: from dggpemm500017.china.huawei.com (7.185.36.178) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 29 Mar 2022 17:06:31 +0800 Received: from [10.174.178.220] (10.174.178.220) by dggpemm500017.china.huawei.com (7.185.36.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 29 Mar 2022 17:06:31 +0800 From: Wenchao Hao Subject: [REQUEST DISCUSS]: speed up SCSI error handle for host with massive devices To: , "linux-kernel@vger.kernel.org" , "James E.J. Bottomley" , "Martin K. Petersen" , Mike Christie , Lee Duncan CC: Wu Bo , Feilong Lin , Message-ID: <71e09bb4-ff0a-23fe-38b4-fe6425670efa@huawei.com> Date: Tue, 29 Mar 2022 17:06:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.220] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500017.china.huawei.com (7.185.36.178) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SCSI timeout would call scsi_eh_scmd_add() on some conditions, host would be set to SHOST_RECOVERY state. Once host enter SHOST_RECOVERY, IOs submitted to all devices in this host would not succeed until the scsi_error_handler() finished. The scsi_error_handler() might takes long time to be done, it's unbearable when host has massive devices. I want to ask is anyone applying another error handler flow to address this phenomenon? I think we can move some operations(like scsi get sense, scsi send startunit and scsi device reset) out of scsi_unjam_host(), to perform these operations without setting host to SHOST_RECOVERY? It would reduce the time of block the whole host. Waiting for your discussion.