Messages in this thread | | | Subject | Re: [PATCH 6/6] scsi: hisi_sas: Expose multiple hw queues for v3 as experimental | From | John Garry <> | Date | Tue, 12 Nov 2019 14:35:29 +0000 |
| |
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 > .
| |