From patchwork Fri Jan 22 02:33:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 369118 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F7AEC433E0 for ; Fri, 22 Jan 2021 02:37:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1FAD622DFA for ; Fri, 22 Jan 2021 02:37:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726779AbhAVCgn (ORCPT ); Thu, 21 Jan 2021 21:36:43 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:21224 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726760AbhAVCg1 (ORCPT ); Thu, 21 Jan 2021 21:36:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611282901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lPxOXpRZEK8+IoExIpG2BMHmyj4cl+h7wOpVuwGrBn8=; b=RTnMlPc6kWHwiZ0/jPPuAWOCjwuMEbT8on5gpOg83vr1RxztNjfEyQYTpu0kckfmvSC8IA tWGrbx3uSv67dRLqawOwAjYU2NwtdGJ7aSBgOl+KOEFYudpEWJqrMLsso7KaEo+J7a3Ccd RKOWmQmuJwVNND8wKu3PD5VfQNyOK4I= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-515-c7_6KW1mPpicUIYmNJzsnA-1; Thu, 21 Jan 2021 21:34:57 -0500 X-MC-Unique: c7_6KW1mPpicUIYmNJzsnA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B54E6107ACE3; Fri, 22 Jan 2021 02:34:55 +0000 (UTC) Received: from localhost (ovpn-13-11.pek2.redhat.com [10.72.13.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id EB9A96362B; Fri, 22 Jan 2021 02:34:54 +0000 (UTC) From: Ming Lei To: Jens Axboe , linux-block@vger.kernel.org, "Martin K . Petersen" , linux-scsi@vger.kernel.org Cc: Ming Lei , Omar Sandoval , Kashyap Desai , Sumanesh Samanta , "Ewan D . Milne" , Hannes Reinecke Subject: [PATCH V7 12/13] scsi: make sure sdev->queue_depth is <= max(shost->can_queue, 1024) Date: Fri, 22 Jan 2021 10:33:16 +0800 Message-Id: <20210122023317.687987-13-ming.lei@redhat.com> In-Reply-To: <20210122023317.687987-1-ming.lei@redhat.com> References: <20210122023317.687987-1-ming.lei@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org Limit scsi device's queue depth is less than max(host->can_queue, 1024) in scsi_change_queue_depth(), and 1024 is big enough for saturating current fast SCSI LUN(SSD, or raid volume on multiple SSDs). Also single hw queue depth is usually enough for saturating single LUN because per-core performance is often considered in storage design. We need this patch for replacing sdev->device_busy with sbitmap which has to be pre-allocated with reasonable max depth. Cc: Omar Sandoval Cc: Kashyap Desai Cc: Sumanesh Samanta Cc: Ewan D. Milne Tested-by: Sumanesh Samanta Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei --- drivers/scsi/scsi.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index 24619c3bebd5..a28d48c850cf 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -214,6 +214,15 @@ void scsi_finish_command(struct scsi_cmnd *cmd) scsi_io_completion(cmd, good_bytes); } + +/* + * 1024 is big enough for saturating the fast scsi LUN now + */ +static int scsi_device_max_queue_depth(struct scsi_device *sdev) +{ + return max_t(int, sdev->host->can_queue, 1024); +} + /** * scsi_change_queue_depth - change a device's queue depth * @sdev: SCSI Device in question @@ -223,6 +232,8 @@ void scsi_finish_command(struct scsi_cmnd *cmd) */ int scsi_change_queue_depth(struct scsi_device *sdev, int depth) { + depth = min_t(int, depth, scsi_device_max_queue_depth(sdev)); + if (depth > 0) { sdev->queue_depth = depth; wmb();