Re: HEADS UP: Major CAM performance regression

Hi Scott,

I just tried this on 7.1-p2 with an Areca (arcmsr) controller with SATA 
drives attached to see if it fixed the performance problem I noticed 
back in December 2008.  See:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=43971+0+archive/2008/freebsd-stable/20081207.freebsd-stable

The performance is still terrible.  Interestingly, running your 
camcontrol command returns "device openings" of 1 on 7.1, and 255 on 
6.4, so it seems to be the same underlying problem.

I am happy to try other patches.

Thanks,

Jan Mikkelsen


Scott Long wrote:
> All,
> 
> A major performance regression was introduced to the CAM subsystem in
> FreeBSD 7.1.  The following configurations are known to be affected:
> 
> VMWare ESX
> VMWare Fusion
>     (using bt or lsilogic controller options)
> HP CISS RAID
> Some MPT-SAS combinations with SATA drives attached
>     (Includes Dell SAS5/ir, but not PERC5/PERC6).
> 
> Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
> that uses the 'ata' driver is also definitely NOT affected.  To 
> determine if your installation is affected, run the following command as 
> root:
> 
> camcontrol tags da0
> 
> Substitute 'da0' with another appropriate drive device number, if
> needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
> 'ad' devices, they are NOT affected.
> 
> The result from running this command should be an output similar to the
> following:
> 
> (pass0:mpt0:0:8:0): device openings: 255
> 
> If, instead, it reports a value of '1', you are likely affected.  Note
> that it may be normal for USB memory devices to report a low number.
> Also, many legacy SCSI disks, and devices that are not disks, may also 
> be expected to report a low number.
> 
> The effect of this problem is that only one I/O command will be issued
> to the controller and disk at a time, instead of overlapping multiple
> commands in parallel.  This causes significantly higher latency in
> servicing moderate and heavy I/O workloads, leading to very poor
> performance.  Performance can be easily compared by downgrading to
> FreeBSD 7.0.
> 
> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
> days once I've gotten confirmation that the fix works and doesn't cause
> any adverse side-effects.  Anyone wanting to help in this validation
> effort should apply the attached patch to their kernel source tree and
> recompile.  Please contact me directly by email to report if the problem
> is fixed for you.
> 
> If the validation process goes smoothly, I will work with the release
> engineering team to turn this fix into an official errata update for
> FreeBSD 7.1.
> 
> Thanks in advance for your help.
> 
> Scott
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> freebsd-stable_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe_at_freebsd.org"