lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Feb 2016 10:12:50 +0000 From: John Garry <john.garry@...wei.com> To: Hannes Reinecke <hare@...e.de>, <JBottomley@...n.com>, <martin.petersen@...cle.com> CC: <linuxarm@...wei.com>, <zhangfei.gao@...aro.org>, <xuwei5@...ilicon.com>, <john.garry2@...l.dcu.ie>, <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure() On 18/02/2016 07:40, Hannes Reinecke wrote: > On 02/16/2016 05:56 PM, John Garry wrote: >> On 16/02/2016 15:33, Hannes Reinecke wrote: >>> On 02/16/2016 01:22 PM, John Garry wrote: >>>> In high-datarate aging tests, it is found that >>>> the SCSI framework can periodically >>>> issue lu resets to the device. This is because scsi >>>> commands begin to timeout. It is found that TASK SET >>>> FULL may be returned many times for the same command, >>>> causing the timeouts. >>>> To overcome this, the queue depth for the device needs >>>> to be reduced to 64 (from 256, set in >>>> sas_slave_configure()). >>>> >>> Hmm. TASK SET FULL should cause the queue depth to be reduced >>> automatically, no? >>> >>> Cheers, >>> >>> Hannes >>> >> >> I need to double-check if Task set full reduces the depth, I don't >> think it does. >> >> Regardless I found we were getting a combination of commands being >> retried due to Task Set Full and also SAS_QUEUE_FULL errors. For >> sure the SAS_QUEUE_FULL task errors reduce the queue depth in >> scsi_track_queue_full(). However I found it to be very slow in >> tracking, and we were getting commands timing out before the queue >> depth fell enough. >> >> It would be nice to change default queue depth in >> sas_slave_configure() to a lower value so we can avoid this patch, >> but I am not sure if other vendor's HBA performance would be >> affected. From looking at the history of sas_slave_configure(), it >> would seem the value of 256 was inherited from mpt2sas driver, so >> I'm not sure. >> > Well, the classical thing would be to associate each request tag > with a SAS task; or, in your case, associate each slot index with a > request tag. > You probably would need to reserve some slots for TMFs, ie you'd > need to decrease the resulting ->can_queue variable by that. > But once you've done that you shouldn't hit any QUEUE_FULL issues, > as the block layer will ensure that no tags will be reused while the > command is in flight. > Plus this is something you really need to be doing if you ever > consider moving to scsi-mq ... > > Cheers, > > Hannes > Hi, So would you recommend this method under the assumption that the can_queue value for the host is similar to the queue depth for the device? Regards, John
Powered by blists - more mailing lists