Re: [Qemu-devel] [RFC] Use O_DSYNC by default and update documentation to explain IO integrity in QEMU

[Avi Kivity]

Anthony Liguori wrote:
>  
> +By default, QEMU accesses all disk data through the host's page cache.
> +This allows the host to perform read-ahead and to avoid duplicating IO
>   

The guest does read-ahead as well, so this is not a good thing.  
Further, if using qcow2, host read ahead will read random data, and if 
using raw devices, host read ahead is equivalent to physical read ahead, 
whereas most OSes prefer logical (file based) read ahead.

> +requests unnecessarily increasing disk performance.  You may notice that
> +certain benchmarks in the guest perform better than they do in the host
> +(for read) because of this.  This is primarily because the benchmark is
> +unaware of the extra level of caching that is occurring when running in
> +a virtual environment.
>   

This is because the the guest is effectively running with a much larger 
cache.  If you'd given the guest this memory, it would perform even better.

IMO the only case where having the cache in the host is preferable is 
when the guest cannot utilize the memory effectively, such as when the 
guest reboots, or with older versions of Windows x86.

> +
> +The cache=off option can be used to disable the use of the host's page
> +cache.  Disabling the use of the host's page cache will likely reduce
> +performance since the host is unable to perform read-ahead and unable
> +to avoid duplicating IO requests.  At this time, QEMU will copy data
> +internally so the cost of copying data into the host's page cache is
> +unlikely to be statistically significant.
>   

It's a mistake to optimize for the current state of affairs which we are 
planning to change soon.

> +In the future, QEMU will be able to avoid copying data internally and
> +under certain workloads, disabling the use of the host's page cache may
> +increase performance provided that the guest is actively working to avoid
> +bringing data into the CPU's cache.  This can only be achieved when using
> +things like sendfile() in the guest or other forms of direct-io.

Guest read ahead, write back, and pageout are also examples of transfers 
that are very likely to benefit from not touching the cache.  Other 
examples are the guest reading a metadata block and only accessing one 
inode.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.