-------- Original Message --------
Subject: Re: sync guest calls made async on host - SQLite performance
From: Avi Kivity <avi@xxxxxxxxxx>
To: Matthew Tippett <tippettm@xxxxxxxxx>
Cc: Dustin Kirkland <dustin.kirkland@xxxxxxxxx>, Anthony Liguori
<anthony@xxxxxxxxxxxxx>, RW <kvm@xxxxxxxxxxx>, kvm@xxxxxxxxxxxxxxx
Date: 10/07/2009 04:12 PM
What is the data set for this benchmark? If it's much larger than guest
RAM, but smaller than host RAM, you could be seeing the effects of read
caching.
2GB for host, 1.7GB accessible for the guest (although highly unlikely
that the memory usage went very high at all.
Another possiblity is barriers and flushing.
That is what I am expecting, remember that the host and the guest were
the same OS, same config, nothing special. So the variable in the mix
is how Ubuntu Karmic interacts with the bare metal vs the qemu-kvm
virtual metal.
The test itself is simply 12500 sequential inserts, designed to model a
simple high-transactional load single-tier system. I still have some
investigations pending on how sqlite responds at the syscall level, but
I believe it is requesting synchronous writes and then doing many writes.
The consequence of the structure of the benchmark is that if there is
any caching occurring at all from the sqlite library down, then it tends
to show. And I believe that it is unexpectedly showing here (since the
writes are expected to be synchronous to a physical disk).
If there is a clear rationale that the KVM community is comfortable
with, then it becomes a distribution or deployment issue relative to
data integrity where a synchronous write within a guest may not be
synchronous to a physical disk. I assume this would concern commercial
and server users of virtual machines.
Regards,
Matthew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
