Date: Tue, 17 Feb 2009 16:54:42 +1100 From: Jan Mikkelsen <janm@transactionware.com> To: Scott Long <scottl@samsco.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: HEADS UP: Major CAM performance regression Message-ID: <499A5122.1070605@transactionware.com> In-Reply-To: <499551B9.7050805@samsco.org> References: <499551B9.7050805@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?499A5122.1070605>