From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: pvUSB backend performance Date: Mon, 29 Jun 2015 15:53:57 +0200 Message-ID: <55914DF5.2050102@suse.com> References: <558A9D2A.2020006@suse.com> <55914C32.6040105@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55914C32.6040105@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/29/2015 03:46 PM, David Vrabel wrote: > On 24/06/15 13:06, Juergen Gross wrote: >> Hi, >> >> my qemu integrated pvUSB backend is now running stable enough to do >> some basic performance measurements. I've passed a memory-stick with >> about 90MB of data on it to a pv-domU. Then I read all the data on >> it with tar and looked how long this would take (elapsed time): >> >> in dom0: 5.2s >> in domU with kernel backend: 6.1s >> in domU with qemu backend: 8.2s >> >> So the qemu backend is about 30% slower than the kernel backend. Is >> this acceptable? > > Yes? Maybe? I assume you're adding this backend for a reason, so is it > good enough for your workloads? We (SUSE) have a kernel based backend in SLE and openSUSE. I'm pretty sure it isn't used for really performance critical stuff right now. But having an upstream variant might change this, so I'd rather ask before adding the qemu variant and having to do the kernel solution afterwards as well. :-) > IMO, It seems a reasonable trade off to not have a bunch of kernel code. Yeah, this would be my gut feeling, too. Juergen