From: John Garry <john.garry@huawei.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: <jejb@linux.vnet.ibm.com>, <martin.petersen@oracle.com>,
<linux-scsi@vger.kernel.org>, <linuxarm@huawei.com>,
<linux-kernel@vger.kernel.org>, <hare@suse.com>,
chenxiang <chenxiang66@hisilicon.com>
Subject: Re: [PATCH 6/6] scsi: hisi_sas: Expose multiple hw queues for v3 as experimental
Date: Tue, 12 Nov 2019 14:35:29 +0000 [thread overview]
Message-ID: <fca9ae03-783a-e5cd-b517-d3f87be9fa5e@huawei.com> (raw)
In-Reply-To: <a8a83145-9498-9ed6-0510-5d51eda22f54@huawei.com>
On 12/11/2019 13:54, John Garry wrote:
>>>
>>> I mentioned in the thread "blk-mq: improvement on handling IO during CPU
>>> hotplug" that I was using this series to test that patchset.
>>>
>>> So just with this patchset (and without yours), I get what looks like
>>> some
>>> IO errors in the LLDD. The error is an underflow error. I can't
>>> figure out
>>> what is the cause.
>>
>
> Hi Ming,
>
>> Can you post the error log? Or interpret the 'underflow error' from hisi
>> sas or scsi viewpoint?
>
> The check here fails:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/libsas/sas_scsi_host.c?h=v5.4-rc7#n57
>
>
> Indeed, no data is received.
>
>>
>>>
>>> I'm wondering if the SCSI command is getting corrupted someway.
>>
>> Why do you think the command is corrupted?
>
> I considered that the underflow may occur if we were to clobber a SCSI
> command/request from another hctx and zero some fields, which is
> detected as an underflow. But that's just guessing.
>
> However do I find if I set shost->can_queue = HISI_SAS_MAX_COMMANDS /
> #queues, then no issue But maybe that's a coincidence. For this, total
> queue depth = HISI_SAS_MAX_COMMANDS. I don't see the impact of that.
>
Scratch that. I have seen the issue here also.
Thanks,
John
> I need to test that more.
>
>>
>>>
>>>>> + if (expose_mq_experimental) {
>>>>> + shost->can_queue = HISI_SAS_MAX_COMMANDS;
>>>>> + shost->cmd_per_lun = HISI_SAS_MAX_COMMANDS;
>>>> The above is contradictory with current 'nr_hw_queues''s meaning,
>>>> see commit on Scsi_Host.nr_hw_queues.
>>>>
>>>
>>> Right, so I am generating the hostwide tag in the LLDD. And the Scsi
>>> host-wide host_busy counter should ensure that we don't pump too much
>>> IO to
>>> the HBA.
>>
>> Even without the host-wide host_busy, your approach should work if you
>> build the hisi sas tag correctly(uniquely), just not efficiently.
>
> Yes, I do that.
>
> I'd
>> suggest you to collect trace and observe if request with expected hisi
>> sas
>> tag is sent to hardware.
>>
>
> I can add some debug for that. What trace do you mean?
>
>> BTW, the patch of 'scsi: core: avoid host-wide host_busy counter for
>> scsi_mq'
>> will be merged to v5.5 if everything is fine.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=5.5/scsi-queue&id=6eb045e092efefafc6687409a6fa6d1dabf0fb69
>>
>
> Yeah, it seems a good change.
>
> Thanks,
> John
> .
next prev parent reply other threads:[~2019-11-12 14:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 14:21 [PATCH 0/6] hisi_sas: Expose multiple hw queues for v3 hw as experimental John Garry
2019-10-24 14:21 ` [PATCH 1/6] scsi: hisi_sas: Use sbitmap for IPTT management John Garry
2019-10-24 14:21 ` [PATCH 2/6] scsi: hisi_sas: Pass scsi_cmnd pointer to hisi_sas_hw.slot_index_alloc John Garry
2019-10-24 14:21 ` [PATCH 3/6] scsi: hisi_sas: Add bitmaps_alloc_v3_hw() John Garry
2019-10-24 14:21 ` [PATCH 4/6] scsi: hisi_sas: Add slot_index_alloc_v3_hw() and slot_index_free_v3_hw() John Garry
2019-10-24 14:21 ` [PATCH 5/6] scsi: hisi_sas: Split interrupt_init_v3_hw() John Garry
2019-10-24 14:21 ` [PATCH 6/6] scsi: hisi_sas: Expose multiple hw queues for v3 as experimental John Garry
2019-10-27 8:19 ` Ming Lei
2019-11-11 14:02 ` John Garry
2019-11-12 11:10 ` Ming Lei
2019-11-12 13:54 ` John Garry
2019-11-12 14:35 ` John Garry [this message]
2019-10-25 16:04 ` [PATCH 0/6] hisi_sas: Expose multiple hw queues for v3 hw " John Garry
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=fca9ae03-783a-e5cd-b517-d3f87be9fa5e@huawei.com \
--to=john.garry@huawei.com \
--cc=chenxiang66@hisilicon.com \
--cc=hare@suse.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.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.