From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0OGC-0006tz-Eu for qemu-devel@nongnu.org; Fri, 27 Jun 2014 00:59:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0OG3-0005wm-2S for qemu-devel@nongnu.org; Fri, 27 Jun 2014 00:59:40 -0400 Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:63867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0OG2-0005wi-Rj for qemu-devel@nongnu.org; Fri, 27 Jun 2014 00:59:30 -0400 Received: by mail-wg0-f42.google.com with SMTP id z12so4564656wgg.13 for ; Thu, 26 Jun 2014 21:59:30 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53ACFA2E.8080901@redhat.com> Date: Fri, 27 Jun 2014 06:59:26 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <53AC3C72.6080308@redhat.com> <53AC3F8E.20808@redhat.com> <53AC42DA.2000703@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [regression] dataplane: throughout -40% by commit 580b6b2aa2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , "Michael S. Tsirkin" Il 27/06/2014 03:15, Ming Lei ha scritto: > On Thu, Jun 26, 2014 at 11:57 PM, Paolo Bonzini wrote: >> We can implement (advisory) calls like bdrv_plug/bdrv_unplug in order to >> restore the previous levels of performance. > > Yes, that is also what I am thinking, or interfaces like bdrv_queue_io() > and bdrv_submit_io(), which may match with aio interfaces. Would you like to try preparing a patch? >> >> Note that some fallout of the conversion was expected. Dataplane told us >> experimentally what level of performance could be reached, but was a dead >> end in terms of functionality. Now Stefan added a whole lot of >> functionality to dataplane (accounting, throttling, file formats and >> protocols, thread-pool based I/O, etc.) and we need to bring back any >> performance we lost in the process. > > These features are very good, but looks the conversion is a bit early, :-( Dataplane is still (and has always been) experimental. For now, it's a playground to get rid of the big QEMU lock in hot paths. As such, performance going up and down is expected. The good thing is that every performance improvement we do now will not be restricted to dataplane, it can be applied just as well to any other device. Paolo