Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Feb 2009 07:33:25 -0700
From:      Scott Long <scottl@samsco.org>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: HEADS UP: Major CAM performance regression
Message-ID:  <4996D635.3000802@samsco.org>
In-Reply-To: <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
References:  <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>	 <4995DFE5.1020205@samsco.org> <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote:
> 2009/2/13 Scott Long <scottl@samsco.org>:
>> Ivan Voras wrote:
>>> Scott Long wrote:
>>>
>>>> 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.
>>> I notice that write performance on an ESXi 3.5 hosted system is doubled,
>>> but read performance remains the same (in bonnie++).
>>> On a CISS system there is no significant change.
>> bonnie is an unreliable tool for measuring performance.
> 
> I'll try your suggestion if you have one.

I don't have a magic universal testing suite in my back pocket, sorry.
You need to look at your expected workload and develop tests to simulate
it.  When I do testing during driver development, I try a lot of
different parallel, sequential, large i/o, and small i/o combinations.

> 
> (except if it's about bonnie++ primarily measuring sequential
> read/write - if a system can't do sequential IO well, it probably
> won't do random IO well)

This is completely false.  Disks can't do sequential i/o very well due
to the physical limits of long seek times, but those seek times can be
greatly amortized, even in a random workload, with tagged queueing and
parallel dispatch from the OS.  Bonnie simply cannot exercise this very
well.

Bonnie tests system latency for discrete I/O's.  That is all it tests.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4996D635.3000802>