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.
