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