From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKQJ1-00028i-RL for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:41:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKQIv-0003ci-N2 for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:41:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKQIv-0003cc-DC for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:41:01 -0500 Date: Mon, 3 Mar 2014 11:40:54 +0100 From: Kevin Wolf Message-ID: <20140303104054.GC4850@dhcp-200-207.str.redhat.com> References: <530DBE6C.5030502@kamp.de> <20140226154154.GB20820@stefanha-thinkpad.muc.redhat.com> <20140227011031.GC1050@T430> <20140227110741.GC3667@dhcp-200-207.str.redhat.com> <530F6401.8020501@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530F6401.8020501@kamp.de> Subject: Re: [Qemu-devel] qemu-img convert cache mode for source List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Stefan Hajnoczi , Fam Zheng , "qemu-devel@nongnu.org" , Stefan Hajnoczi , Paolo Bonzini 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