Btw, I suppose `.can_queue = MAX_CMNDS` in the host template is unnecessary (unless we are going to revert `shost->can_queue = devinfo->qdepth - 2`)? On 22 May 2016 at 18:39, Tom Yan <tom.ty89@xxxxxxxxx> wrote: > With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer > set `queue_depth` with scsi_change_queue_depth(), so now `queue_depth` > of UAS drives are 1. Even though `can_queue` is set to > `devinfo->qdepth - 2`, but apparently that does not help, since I can > see performance impact. > > Suppose limiting `can_queue` is the right way to fix this bug > (https://bugzilla.redhat.com/show_bug.cgi?id=1315013), do we really > need to eliminate scsi_change_queue_depth() at the same time though? > If so, how should we deal with the regression? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
