qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] rbd: add an asynchronous flush


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2] rbd: add an asynchronous flush
Date: Fri, 12 Apr 2013 09:42:35 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Apr 12, 2013 at 08:50:35AM +0200, Kevin Wolf wrote:
> Am 11.04.2013 um 19:19 hat Josh Durgin geschrieben:
> > On 04/11/2013 01:48 AM, Kevin Wolf wrote:
> > >Am 11.04.2013 um 10:02 hat Stefan Hajnoczi geschrieben:
> > >>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?
> > >
> > >Only patch 1/2 would add dead code as .bdrv_aio_flush would never be
> > >called. I think we should rather take v1 of the series then, with the
> > >#ifdefs at build time.
> > 
> > Yes, that would be a problem with only v3 1/2. v2 of the original
> > series is fine, but v1 was accidentally missing a hunk. To be clear,
> > I think just http://patchwork.ozlabs.org/patch/232489/ would be good.
> 
> Yes, sorry, I should have checked before posting this. v2 I meant.

Thanks Josh and Kevin.  Will take v2.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]