On Thu, 2018-01-11 at 17:07 -0500, Mike Snitzer wrote: > Bart, if for some reason we regress for some workload you're able to > more readily test we can deal with it. But I'm too encouraged by Ming's > performance improvements to hold these changes back any further. Sorry Mike but I think Ming's measurement results are not sufficient to motivate upstreaming of these patches. What I remember from previous versions of this patch series is that Ming measured the performance impact of this patch series only for the Emulex FC driver (lpfc). That driver limits queue depth to 3. Instead of modifying the dm code, that driver needs to be fixed such that it allows larger queue depths. Additionally, some time ago I had explained in detail why I think that patch 2/5 in this series is wrong and why it will introduce fairness regressions in multi-LUN workloads. I think we need performance measurements for this patch series for at least the following two configurations before this patch series can be considered for upstream inclusion: * The performance impact of this patch series for SCSI devices with a realistic queue depth (e.g. 64 or 128). * The performance impact for this patch series for a SCSI host with which multiple LUNs are associated and for which the target system often replies with the SCSI "BUSY" status. Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
