From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQCSu-0002D0-2R for qemu-devel@nongnu.org; Thu, 11 Apr 2013 04:02:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQCSr-0004xh-Ae for qemu-devel@nongnu.org; Thu, 11 Apr 2013 04:02:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQCSr-0004xG-3q for qemu-devel@nongnu.org; Thu, 11 Apr 2013 04:02:37 -0400 Date: Thu, 11 Apr 2013 10:02:32 +0200 From: Stefan Hajnoczi Message-ID: <20130411080232.GB5253@stefanha-thinkpad.redhat.com> References: <1364543983-8180-1-git-send-email-josh.durgin@inktank.com> <1364587403-30689-1-git-send-email-josh.durgin@inktank.com> <20130402141042.GL2341@dhcp-200-207.str.redhat.com> <5165713B.8070003@inktank.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5165713B.8070003@inktank.com> Subject: Re: [Qemu-devel] [PATCH v2] rbd: add an asynchronous flush List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Josh Durgin Cc: Kevin Wolf , qemu-devel@nongnu.org On Wed, Apr 10, 2013 at 07:03:39AM -0700, Josh Durgin wrote: > On 04/02/2013 07:10 AM, Kevin Wolf wrote: > >Am 29.03.2013 um 21:03 hat Josh Durgin geschrieben: > >>The existing bdrv_co_flush_to_disk implementation uses rbd_flush(), > >>which is sychronous and causes the main qemu thread to block until it > >>is complete. This results in unresponsiveness and extra latency for > >>the guest. > >> > >>Fix this by using an asynchronous version of flush. This was added to > >>librbd with a special #define to indicate its presence, since it will > >>be backported to stable versions. Thus, there is no need to check the > >>version of librbd. > > > >librbd is linked dynamically and the version on the build host isn't > >necessarily the same as the version qemu is run with. So shouldn't this > >better be a runtime check? > > While we discuss runtime loading separately, would you mind taking this > patch as-is for now? Hi Josh, I'm happy with Patch v3 1/2. Does that work for you? I don't want to take Patch v3 2/2 or the dlsym() function pointer patch. Stefan