linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Anand Lodnoor <anand.lodnoor@broadcom.com>
Cc: Hannes Reinecke <hare@suse.de>, <linux-scsi@vger.kernel.org>,
	"Kashyap Desai" <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>,
	Sankar Patra <sankar.patra@broadcom.com>,
	Sasikumar PC <sasikumar.pc@broadcom.com>,
	Shivasharan Srikanteshwara 
	<shivasharan.srikanteshwara@broadcom.com>,
	Chandrakanth Patil <chandrakanth.patil@broadcom.com>,
	Ming Lei <ming.lei@redhat.com>,
	Bart Van Assche <bvanassche@acm.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v2 10/11] megaraid_sas: Use Block layer API to check SCSI device in-flight IO requests
Date: Thu, 27 Feb 2020 12:32:02 +0000	[thread overview]
Message-ID: <93deab34-53a3-afcf-4862-6b168a9f60cc@huawei.com> (raw)
In-Reply-To: <CAAO+jF-P3MkB2mo6pmYH1ihjRGpfjkkgXZg9dAZ29nYmU6T2=A@mail.gmail.com>

> 
>     Is blk_mq_hw_ctx.nr_active really the same as scsi_device.device_busy?
> 
> *Both of them are not the same but it serves our purpose to get the 
> number of outstanding io requests. Please refer below link for more 
> details:*
> 
> https://lore.kernel.org/linux-scsi/20191105002334.GA11436@ming.t460p/

Thanks for the pointer, but there did not seem to be a conclusion there: 
https://lore.kernel.org/linux-scsi/20191105002334.GA11436@ming.t460p/

Anyway, if we move to exposing multiple HW queues in the megaraid SAS 
driver:

  host->nr_hw_queues = instance->msix_vectors -
                       instance->low_latency_index_start;

Then hctx->nr_active will no longer be the total active requests per 
host, but rather per hctx.

In addition, hctx->nr_active will no longer be properly maintained, as 
it would be based on the hctx HW queue actually being used by the LLDD 
for that request, which is not always true now. That is because in 
megasas_get_msix_index() a judgement may be made to use a low-latency HW 
queue instead:

static inline void
megasas_get_msix_index(struct megasas_instance *instance,
		       struct scsi_cmnd *scmd,
		       struct megasas_cmd_fusion *cmd,
		       u8 data_arms)
{
...

sdev_busy = atomic_read(&hctx->nr_active);

if (instance->perf_mode == MR_BALANCED_PERF_MODE &&
     sdev_busy > (data_arms * MR_DEVICE_HIGH_IOPS_DEPTH))
	cmd->request_desc->SCSIIO.MSIxIndex =
			mega_mod64(...),
	else if (instance->msix_load_balance)
		cmd->request_desc->SCSIIO.MSIxIndex =
			(mega_mod64(...),
				instance->msix_vectors));

Will this make a difference? I am not sure. Maybe, on this basis, 
magaraid sas is not a good candidate to change to expose multiple queues.

Ignoring that for a moment, since we no longer keep a host busy count, 
and I figure that we don't want to back to using 
scsi_device.device_busy, is the judgement of hctx->nr_active ok to use 
to decide whether to use these performance queues?

Thanks,
John

  parent reply	other threads:[~2020-02-27 12:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 11:21 [PATCH v2 00/11] megaraid_sas: driver updates to 07.713.01.00-rc1 Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 01/11] megaraid_sas: Reset adapter if FW is not in READY state after device resume Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 02/11] megaraid_sas: Set no_write_same only for Virtual Disk Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 03/11] megaraid_sas: Update optimal queue depth for SAS and NVMe devices Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 04/11] megaraid_sas: Do not kill host bus adapter, if adapter is already dead Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 05/11] megaraid_sas: Do not kill HBA if JBOD Seqence map or RAID map is disabled Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 06/11] megaraid_sas: Do not set HBA Operational if FW is not in operational state Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 07/11] megaraid_sas: Re-Define enum DCMD_RETURN_STATUS Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 08/11] megaraid_sas: Do not initiate OCR if controller is not in ready state Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 09/11] megaraid_sas: Limit the number of retries for the IOCTLs causing firmware fault Anand Lodnoor
2020-01-14 11:21 ` [PATCH v2 10/11] megaraid_sas: Use Block layer API to check SCSI device in-flight IO requests Anand Lodnoor
2020-01-16 12:30   ` Hannes Reinecke
2020-01-17 11:19     ` Anand Lodnoor
2020-02-26 16:19       ` John Garry
     [not found]         ` <CAAO+jF-P3MkB2mo6pmYH1ihjRGpfjkkgXZg9dAZ29nYmU6T2=A@mail.gmail.com>
2020-02-27 12:32           ` John Garry [this message]
2020-03-02  9:17             ` Hannes Reinecke
2020-03-02  9:51               ` John Garry
2020-03-02 18:37                 ` Sumit Saxena
2020-03-03 11:53                   ` John Garry
2020-03-03 11:56                     ` Hannes Reinecke
2020-03-03 17:04                     ` Sumit Saxena
2020-03-04  9:39                       ` John Garry
2020-01-14 11:21 ` [PATCH v2 11/11] megaraid_sas: Update driver version to 07.713.01.00-rc1 Anand Lodnoor
2020-01-16  4:21 ` [PATCH v2 00/11] megaraid_sas: driver updates " Martin K. Petersen

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=93deab34-53a3-afcf-4862-6b168a9f60cc@huawei.com \
    --to=john.garry@huawei.com \
    --cc=anand.lodnoor@broadcom.com \
    --cc=bvanassche@acm.org \
    --cc=chandrakanth.patil@broadcom.com \
    --cc=hare@suse.de \
    --cc=kashyap.desai@broadcom.com \
    --cc=kiran-kumar.kasturi@broadcom.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=sankar.patra@broadcom.com \
    --cc=sasikumar.pc@broadcom.com \
    --cc=shivasharan.srikanteshwara@broadcom.com \
    --cc=sumit.saxena@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).