-------- Original Message  --------
Subject: Re: sync guest calls made async on host - SQLite performance
From: Avi Kivity <avi@redhat.com>
To: Matthew Tippett <tippettm@gmail.com>
Cc: Dustin Kirkland <dustin.kirkland@gmail.com>, Anthony Liguori 
<anthony@codemonkey.ws>, RW <kvm@tauceti.net>, kvm@vger.kernel.org
Date: 10/07/2009 04:12 PM

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

quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html