[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-img convert cache mode for source
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] qemu-img convert cache mode for source |
Date: |
Mon, 3 Mar 2014 11:40:54 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 27.02.2014 um 17:12 hat Peter Lieven geschrieben:
> Am 27.02.2014 12:07, schrieb Kevin Wolf:
> > 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.
> Yes, you have pointed that out before. How complicated is it to fix this?
I don't think it should be very complicated, but it basically means a
rewrite of the PIO read/write code, so there are chances to introduce
new bugs.
Kevin
- Re: [Qemu-devel] qemu-img convert cache mode for source, Kevin Wolf, 2014/03/03
- Re: [Qemu-devel] qemu-img convert cache mode for source,
Kevin Wolf <=
- Re: [Qemu-devel] qemu-img convert cache mode for source, Stefan Hajnoczi, 2014/03/03
- Re: [Qemu-devel] qemu-img convert cache mode for source, Peter Lieven, 2014/03/03
- Re: [Qemu-devel] qemu-img convert cache mode for source, Stefan Hajnoczi, 2014/03/04
- Re: [Qemu-devel] qemu-img convert cache mode for source, Peter Lieven, 2014/03/05
- Re: [Qemu-devel] qemu-img convert cache mode for source, Marcus, 2014/03/05
- Re: [Qemu-devel] qemu-img convert cache mode for source, Peter Lieven, 2014/03/05
- Re: [Qemu-devel] qemu-img convert cache mode for source, Marcus, 2014/03/05
- Re: [Qemu-devel] qemu-img convert cache mode for source, Peter Lieven, 2014/03/05
- Re: [Qemu-devel] qemu-img convert cache mode for source, Stefan Hajnoczi, 2014/03/06
- Re: [Qemu-devel] qemu-img convert cache mode for source, Peter Lieven, 2014/03/06