HEADS UP: Major CAM performance regression

[Ivan Voras]

2009/2/14 Scott Long <scottl at 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?).