From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDBH3-0004hW-Gb for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:08:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDBGy-0005g9-Le for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:08:37 -0500 Received: from mail-wg0-f43.google.com ([74.125.82.43]:44112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDBGy-0005g2-FF for qemu-devel@nongnu.org; Wed, 06 Mar 2013 05:08:32 -0500 Received: by mail-wg0-f43.google.com with SMTP id e12so7345308wge.22 for ; Wed, 06 Mar 2013 02:08:31 -0800 (PST) Date: Wed, 6 Mar 2013 11:08:26 +0100 From: Stefan Hajnoczi Message-ID: <20130306100826.GC1954@stefanha-thinkpad.muc.redhat.com> References: <20130305141845.GA3411@irqsave.net> <20130305204629.GA3669@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130305204629.GA3669@irqsave.net> Subject: Re: [Qemu-devel] Dataplane and vhost-blk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: qemu-devel On Tue, Mar 05, 2013 at 09:46:30PM +0100, Benoît Canet wrote: > > You need to set a more specific goal. Some questions to get started: > > * Which workloads do you care about and what are their > > characteristics (sequential or random I/O, queue depth)? > > * Do you care about 1 vcpu guests or 4+ vcpu guests? (SMP scalability) > > * Are you using an image format? > > The usage would be a typical HPC workload: 4 vcpu in SMP and random IO on raw > devices. Okay. If you want to do performance analysis on the existing stack, then the next step is to choose a benchmark that represents this workload. Then you can collect profiles and see where there is room for improvement. In virtio-blk data plane world I'm currently converting core QEMU code to support multiple AioContexts. This is needed in order to use BlockDriverStates from threads (without holding the global mutex). This is a pretty linear task. The second half of this work is enabling device emulation code to run in threads without the global mutex. The trickiest thing here is probably guest memory access - making guest memory access and DMA work safely from a thread. I haven't really started on this, Ping Fan Liu has worked on it in the past, you could chat with him to find out the current status. Stefan