I understand. However the test itself is fairly trivial
representation of a single teir high-transactional load system. (Ie:
a system that is logging a large number of events).
The phoronix test suite simply hands over to a binary using sqlite and
does 25000 sequential inserts. The overhead of the suite would be
measured in milliseconds at the start and end. Over the life of the
test (100-2500 seconds), it becomes insignificant noise.
As I said, the relevant system calls itself for the running of the
test are expressed as
write
write
write
fdatasync
The writes are typically small (5-100) bytes.
With that information, I believe the method of execution is mostly
irrelevant. If people are still concerned, I can write a trivial
application that should reproduce the behaviour.
It still ultimately comes down to the guests expected semantics of
fdatasync, and the actual behaviour relative to the hosts physical
device. I am not saying that the currentl behaviour is wrong, I just
want a clear understanding of what is expected by the kvm team vs what
we are seeing.
Regards... Matthew
On 10/14/09, Dustin Kirkland <[email protected]> wrote:
> On Tue, Oct 13, 2009 at 9:09 PM, Matthew Tippett <[email protected]> wrote:
>> I believe that I have removed the benchmark from discussion, we are now
>> looking at semantics of small writes followed by
> ...
>> And quoting from Dustin
>>
>> ===
>> I have tried this, exactly as you have described. The tests took:
>>
>> * 1162.08033204 seconds on native hardware
>> * 2306.68306303 seconds in a kvm using if=scsi disk
>> * 405.382308006 seconds in a kvm using if=virtio
>
> Hang on now...
>
> My timings are from running the Phoronix test *as you described*. I
> have not looked at what magic is happening inside of this Phoronix
> test. I am most certainly *not* speaking as to the quality or
> legitimacy of the test.
>
> :-Dustin
>
--
Sent from my mobile device
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
