Re: [Qemu-devel] [RFC] Disk integrity in QEMU

[Dor Laor]

Avi Kivity wrote:
> Chris Wright wrote:
> > I think it's safe to say the perf folks are concerned w/ data integrity
> > first, stable/reproducible results second, and raw performance third.
> >
> > So seeing data cached in host was simply not what they expected.  I 
> > think
> > write through is sufficient.  However I think that uncached vs. wt will
> > show up on the radar under reproducible results (need to tune based on
> > cache size).  And in most overcommit scenarios memory is typically more
> > precious than cpu, it's unclear to me if the extra buffering is anything
> > other than memory overhead.  As long as it's configurable then it's
> > comparable and benchmarking and best practices can dictate best choice.
> >   
>
> Getting good performance because we have a huge amount of free memory 
> in the host is not a good benchmark.  Under most circumstances, the 
> free memory will be used either for more guests, or will be given to 
> the existing guests, which can utilize it more efficiently than the host.
>
> I can see two cases where this is not true:
>
> - using older, 32-bit guests which cannot utilize all of the cache.  I 
> think Windows XP is limited to 512MB of cache, and usually doesn't 
> utilize even that.  So if you have an application running on 32-bit 
> Windows (or on 32-bit Linux with pae disabled), and a huge host, you 
> will see a significant boost from cache=writethrough.  This is a case 
> where performance can exceed native, simply because native cannot 
> exploit all the resources of the host.
>
> - if cache requirements vary in time across the different guests, and 
> if some smart ballooning is not in place, having free memory on the 
> host means we utilize it for whichever guest has the greatest need, so 
> overall performance improves.
Another justification for ODIRECT is that many production system will 
use the base images for their VMs.
It's mainly true for desktop virtualization but probably for some server 
virtualization deployments.
In these type of scenarios, we can have all of the base image chain 
opened as default with caching for read-only while the
leaf images are open with cache=off.
Since there is ongoing effort (both by IT and developers) to keep the 
base images as big as possible, it guarantees that
this data is best suited for caching in the host while the private leaf 
images will be uncached.
This way we provide good performance and caching for the shared parent 
images while also promising correctness.
Actually this is what happens on mainline qemu with cache=off.

Cheers,
Dor