Re: [Qemu-devel] qemu-img convert cache mode for source

[Kevin Wolf <kwolf@redhat.com>]

Am 27.02.2014 um 02:10 hat Fam Zheng geschrieben:
> On Wed, 02/26 16:41, Stefan Hajnoczi wrote:
> > On Wed, Feb 26, 2014 at 11:14:04AM +0100, Peter Lieven wrote:
> > > I was wondering if it would be a good idea to set the O_DIRECT mode for the source
> > > files of a qemu-img convert process if the source is a host_device?
> > > 
> > > Currently the backup of a host device is polluting the page cache.
> 
> Peter, can you give some more detailed explanation of the issue? An example or
> benchmark will help a lot. As I understand, one time scanning of a file doesn't
> promote the page cache to active list, so it probably won't hurt real hot cache
> at all, and will get replaced very soon.
> 
> Considering readahead and page cache on metadata, I'm not sure if forcing
> O_DIRECT is a good idea.
> 
> >    The problem is what to do for image formats.  An image file can be
> >    very fragmented so the readahead might not be a win.  Does this mean
> >    that for image formats we should tell the kernel access will be
> >    random?
> > 
> >    Furthermore, maybe it's best to do readahead inside QEMU so that even
> >    network protocols (nbd, iscsi, etc) can get good performance.  They
> >    act like O_DIRECT is always on.
> 
> Also, experience with booting a network backed guest can be greatly improved,
> because sometimes BIOS and bootloader are simple minded and load a kernel or
> initrd by sending thousands of 1 sector requests with iodepth=1, which means
> latency of network based IO hurts a lot.

I think I mentioned it a while ago, but our IDE emulation plays a role
in this as well. PIO requests are always handled sector by sector, no
matter how big the request was that we got from the BIOS.

Kevin

> Doing readahead in QEMU makes sense for image formats as well, because we know
> where the next data cluster is better than kernel. But again, we are
> replicating things from kernel.