Re: [libvirt] PATCH: Disable QEMU drive caching

Anthony Liguori wrote: This is not accurate (at least for HVM guests using PV drivers on Xen 3.2). blkback does indeed bypass the host page cache completely. It's I/O behavior is akin to O_DIRECT. I/O is dma'd directly to/from guest pages without involving any dom0 buffering. blkback barrier support only enforces write ordering of the blkback I/O stream(s). It does nothing to synchronize data in the host page cache. Data written through blkback will modify the storage "underneath" any data in the host page cache (w/o flushing the page cache). Subsequent access to the page cache by qemu-dm will access stale data. In our own Xen product we must explicitly flush the host page cache backing store data at qemu-dm start up, to guarantee proper data access. It is not safe to access the same backing object with both qemu-dm and blkback simultaneously. I don't think this is enough. Barrier semantics are local to a particular I/O stream. There would be no reason for the barrier to affect the host page cache (unless the I/Os are buffered by the cache). I generally agree with your suggestion that host page cache performance benefits shouldn't be discarded just to make naive benchmark data collection easier. Anyone suggesting that QEMU emulated disk I/O could somehow outperform the host I/O system should know that something is wrong with their benchmark setup. Unfortunately this discussion continues to reappear in the Xen community. I am sure that as QEMU/KVM/virtio matures, a similar thread will continue to resurface. Steve