Re: [Qemu-devel] [PATCH v2 4/4] libqos/ahci: Swap memread/write with bufread/write

[John Snow <jsnow@redhat.com>]

On 05/05/2015 06:35 AM, Paolo Bonzini wrote:
>
>
> On 02/05/2015 02:13, John Snow wrote:
>>>
>>
>> I wrote a loop to batch the ascii-hex conversion instead of letting
>> printf do it; then ran some more very, very scientific tests:
>>
>> memset alone:
>> real    0m10.888s
>> user    0m9.303s
>> sys    0m9.146s
>>
>> send-batching:
>> real    0m6.541s
>> user    0m5.027s
>> sys    0m4.941s
>>
>> memset+batching+b64:
>> real    0m3.675s
>> user    0m2.582s
>> sys    0m1.718s
>>
>> So it still seems as if the b64 batching is a strict improvement
>> speed-wise. I'll send the non-b64 batching patch separately later,
>> unless you have thoughts otherwise.
>
> Ok, this is more similar to what I'd expect (3.6 * 6 / 4 = 5.4, I'm not
> sure if you have the memset optimization in the send-batching test).
>

I did, yes. Hence the "very, very scientific" warning. I just pushed 
patches down my stack and tested with each new optimization.

Unoptimized is still ~14s.

> Hex is obviously more debuggable compared to Base64 (unless you starred
> in the Matrix movies), so I'm a bit undecided about this one.  Anyone
> can break the tie?
>
> Paolo
>

I specifically left things that alter control flow using hex nibbles -- 
such as the FIS packets, PRD tables, and all other existing tests. I 
only use the b64 encoding for raw data patterns, which don't really need 
to be debugged. Either they match or they don't: any particular values 
are uninteresting.

Any future test can be switched to/from hex/b64 by just altering 
"mem{read,write}()" to "buf{read,write}()" as desired. I specifically 
opted not to alter *all* qtest IO for this very reason.

Does that help? :)

If you're not opposed to the rest of this series, I will send a v2 
including the hex batching optimization.

--js