From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: pvUSB backend performance Date: Mon, 29 Jun 2015 15:36:28 +0200 Message-ID: <559149DC.8000708@suse.com> References: <558A9D2A.2020006@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 06/29/2015 03:22 PM, George Dunlap wrote: > On Wed, Jun 24, 2015 at 1:06 PM, 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? > > Just to be clear, you mean having qemu act as a pvusb backend (a la > qdisk), not emulated, is that correct? Yes. > I don't actually understand your question -- is the overhead > acceptable for what? Acceptable for the decision to build the backend in qemu only. When I posted the first draft of my kernel backend to lkml the question was raised why I couldn't do this in userland via libusb. > I think in an ideal world the toolstack will use the kernel backend if > it's available, and fall back to a qemu backend if it's not available. In case the performance is regarded to be sufficient I won't retry to push a kernel backend. So there will be none in the near future. If the performance is not good enough I'll give the kernel backend another try. If it's being accepted I probably won't do the qemu one. Juergen