From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIwmV-0008Rn-Hs for qemu-devel@nongnu.org; Thu, 27 Feb 2014 03:57:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIwmP-00075p-Hi for qemu-devel@nongnu.org; Thu, 27 Feb 2014 03:57:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIwmP-00075e-9p for qemu-devel@nongnu.org; Thu, 27 Feb 2014 03:57:21 -0500 Date: Thu, 27 Feb 2014 09:57:11 +0100 From: Stefan Hajnoczi Message-ID: <20140227085711.GC21749@stefanha-thinkpad.redhat.com> References: <530DBE6C.5030502@kamp.de> <20140226154154.GB20820@stefanha-thinkpad.muc.redhat.com> <530E0FF0.20501@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530E0FF0.20501@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: Kevin Wolf , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Paolo Bonzini On Wed, Feb 26, 2014 at 05:01:52PM +0100, Peter Lieven wrote: > On 26.02.2014 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. > >Points to consider: > > > >1. O_DIRECT does not work on Linux tmpfs, you get EINVAL when opening > > the file. A fallback is necessary. > > > >2. O_DIRECT has no readahead so performance could actually decrease. > > The question is, how important is reahead versus polluting page > > cache? > > > >3. For raw files it would make sense to tell the kernel that access is > > sequential and data will be used only once. Then we can get the best > > of both worlds (avoid polluting page cache but still get readahead). > > This is done using posix_fadvise(2). > > > > 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. > your comments are regarding qemu-img convert, right? > How would you implement this? A new open flag because > the fadvise had to goto inside the protocol driver. > > I would start with host_devices first and see how it performs there. > > For qemu-img convert I would issue a FADV_DONTNEED after > a write for the bytes that have been written > (i have tested this with Linux and it seems to work quite well). > > Question is, what is the right paramter for reads? Also FADV_DONTNEED? I think so but this should be justified with benchmark results. Stefan