Re: [PATCH V3 0/5] dm-rq: improve sequential I/O performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux