All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Kuai <yukuai1@huaweicloud.com>
To: kashyap.desai@broadcom.com, sumit.saxena@broadcom.com,
	shivasharan.srikanteshwara@broadcom.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, megaraidlinux.pdl@broadcom.com,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-block <linux-block@vger.kernel.org>,
	"yukuai (C)" <yukuai3@huawei.com>,
	"zhangyi (F)" <yi.zhang@huawei.com>
Subject: Why is MEGASAS_SAS_QD set to 256?
Date: Thu, 24 Nov 2022 11:45:16 +0800	[thread overview]
Message-ID: <1c4d66ca-fe1a-3d1a-d7f9-4981d2fc9eb1@huaweicloud.com> (raw)

Hi,

While upgrading kernel from 4.19 to 5.10, I found that fio 1 thread 4k
sequential io performance is dropped(160Mib -> 100 Mib), root cause is
that queue_depth is changed from 64 to 256.

commit 6e73550670ed1c07779706bb6cf61b99c871fc42
scsi: megaraid_sas: Update optimal queue depth for SAS and NVMe devices

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index bd8184072bed..ddfbe6f6667a 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2233,9 +2233,9 @@ enum MR_PD_TYPE {

  /* JBOD Queue depth definitions */
  #define MEGASAS_SATA_QD        32
-#define MEGASAS_SAS_QD 64
+#define MEGASAS_SAS_QD 256
  #define MEGASAS_DEFAULT_PD_QD  64
-#define MEGASAS_NVME_QD                32
+#define MEGASAS_NVME_QD        64


And with the default nr_requests 256, 256 queue_depth will make the
elevator has no effect, specifically io can't be merged in this test
case. Hence it doesn't make sense to me to set default queue_depth to
256.

Is there any reason why MEGASAS_SAS_QD is changed to 64?

Thanks,
Kuai


             reply	other threads:[~2022-11-24  3:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24  3:45 Yu Kuai [this message]
2022-11-25 12:33 ` Why is MEGASAS_SAS_QD set to 256? John Garry
2022-11-26  1:15   ` Yu Kuai
2022-11-26  2:18     ` Ming Lei
2022-11-26  6:08       ` Yu Kuai
2022-11-26  6:08         ` Yu Kuai
2022-11-27  9:42         ` Ming Lei
2022-11-28  3:09           ` Yu Kuai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c4d66ca-fe1a-3d1a-d7f9-4981d2fc9eb1@huaweicloud.com \
    --to=yukuai1@huaweicloud.com \
    --cc=jejb@linux.ibm.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=megaraidlinux.pdl@broadcom.com \
    --cc=shivasharan.srikanteshwara@broadcom.com \
    --cc=sumit.saxena@broadcom.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.