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

next in thread | previous in thread | raw e-mail | index | archive | help
2009/2/14 Scott Long <scottl@samsco.org>:

>> 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.

Of course you're right about testing for specific workloads -  I just
thought you needed data points "from the field" if the patch is
helping or not.

>> (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

I don't follow this - where are the long seek times in sequential IO?

> 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.

Doesn't tagged queuing serve, among other things, to decrease overall
latency for IOs? Since AFAIK UFS queues multiple IO requests in both
directions (read-ahead and write-behind), shouldn't the benefits of
the patch - liberating the tags - be visible even with sequential IO?

I have the systems on which I tested for a few more days, if you need
the data I can run some other tests (randomio?).



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