From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEbUN-0006VE-HW for qemu-devel@nongnu.org; Tue, 05 Aug 2014 05:57:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEbUF-0000iK-FY for qemu-devel@nongnu.org; Tue, 05 Aug 2014 05:57:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEbUF-0000iE-7x for qemu-devel@nongnu.org; Tue, 05 Aug 2014 05:56:55 -0400 Date: Tue, 5 Aug 2014 11:56:48 +0200 From: Kevin Wolf Message-ID: <20140805095648.GG4391@noname.str.redhat.com> References: <1407209598-2572-1-git-send-email-ming.lei@canonical.com> <20140805093830.GD3186@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Stefan Hajnoczi , Paolo Bonzini Am 05.08.2014 um 11:50 hat Ming Lei geschrieben: > On Tue, Aug 5, 2014 at 5:38 PM, Stefan Hajnoczi wrote: > > On Tue, Aug 05, 2014 at 11:33:01AM +0800, Ming Lei wrote: > >> These patches bring up below 4 changes: > >> - introduce object allocation pool and apply it to > >> virtio-blk dataplane for improving its performance > >> > >> - introduce selective coroutine bypass mechanism > >> for improving performance of virtio-blk dataplane with > >> raw format image > >> > >> - linux-aio changes: fixing for cases of -EAGAIN and partial > >> completion, increase max events to 256, and remove one unuseful > >> fields in 'struct qemu_laiocb' > >> > >> - support multi virtqueue for virtio-blk > > > > Please split up this patch series into separate patch series. > > > > These are independent changes and there is no reason to combine them. > > You're doing yourself a disservice because changes that are ready to be > > applied are getting held up by those that still need more discussion. > > Without previous optimization patches, the mq conversion can't > obtain so much improvement, that is why I put them together. > > Also mq conversion depends on linux-aio fix too. > > Also it becomes a difficult to test these patches if they are splitted, > and describing the dependency is a bit annoying too. > > > That will also make the performance discussions easier to follow since > > each patch series should include performance results, making it easy to > > understand how much improvement each change brings. > > The number can be found inside patches, for example, patch 02 has > the number for using obj pool, and patch 09 has the number for > bypassing coroutine, and patch 17 has the number for mq conversion. A claim like "~5%-10% throughput improvement" isn't numbers nor a precise description of your benchmark setup. Kevin