pvUSB backend performance

pvUSB backend performance

[Juergen Gross]

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?

BTW: I managed not to have to copy the I/O-data in the backend, it is
just mapped into user space and then given to the USB framework of qemu.
I think it will be copied there, but changing this will require a lot
of work...


Juergen

Re: pvUSB backend performance

[Konrad Rzeszutek Wilk]

On Wed, Jun 24, 2015 at 02:06:02PM +0200, 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?

That sounds about right. I remember seeing (two years ago?) an demonstration
by kraxel where he was doing USB camera in a guest. He pointed out
that USB1 (which is default one in QEMU) implementation sucks as QEMU
has to poll for the commands every time. The XHCI implementation is
better as it has some better API, or such (-EFORGOT).

Oh, this has more details:
https://www.kraxel.org/blog/2014/03/qemu-and-usb-tablet-cpu-consumtion/

> 
> BTW: I managed not to have to copy the I/O-data in the backend, it is
> just mapped into user space and then given to the USB framework of qemu.
> I think it will be copied there, but changing this will require a lot
> of work...
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: pvUSB backend performance

[Juergen Gross]

On 06/24/2015 03:57 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 24, 2015 at 02:06:02PM +0200, 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?
>
> That sounds about right. I remember seeing (two years ago?) an demonstration
> by kraxel where he was doing USB camera in a guest. He pointed out
> that USB1 (which is default one in QEMU) implementation sucks as QEMU
> has to poll for the commands every time. The XHCI implementation is
> better as it has some better API, or such (-EFORGOT).
>
> Oh, this has more details:
> https://www.kraxel.org/blog/2014/03/qemu-and-usb-tablet-cpu-consumtion/

This should be no problem in my case. I'm using libusb, so there is no
host adapter emulation active in qemu.


Juergen

Re: pvUSB backend performance

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1020 bytes --]

On Wed, 2015-06-24 at 14:06 +0200, 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?
> 
If I can ask (I know nothing about USB, let alone pvUSB! :-O), and if
you happen to know, what's the situation of other hypervisors, in term
both of support and performance?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvUSB backend performance

[Juergen Gross]

On 06/25/2015 10:53 AM, Dario Faggioli wrote:
> On Wed, 2015-06-24 at 14:06 +0200, 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?
>>
> If I can ask (I know nothing about USB, let alone pvUSB! :-O), and if
> you happen to know, what's the situation of other hypervisors, in term
> both of support and performance?

No specific knowledge, sorry.


Juergen

Re: pvUSB backend performance

[George Dunlap]

On Wed, Jun 24, 2015 at 1:06 PM, Juergen Gross <jgross@suse.com> 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?

I don't actually understand your question -- is the overhead
acceptable for what?

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.

 -George

Re: pvUSB backend performance

[Juergen Gross]

On 06/29/2015 03:22 PM, George Dunlap wrote:
> On Wed, Jun 24, 2015 at 1:06 PM, Juergen Gross <jgross@suse.com> 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

Re: pvUSB backend performance

[David Vrabel]

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?

IMO, It seems a reasonable trade off to not have a bunch of kernel code.

David

Re: pvUSB backend performance

[Juergen Gross]

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

Re: pvUSB backend performance

[George Dunlap]

On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross <jgross@suse.com> wrote:
> On 06/29/2015 03:22 PM, George Dunlap wrote:
>> 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.

So if you're asking for general advice about where we think you might
best spend your time, I don't have much of an opinion; I don't know
who your users are nor what your priorities are as a company.

If you're asking, "Would support for a qemu pv backend be accepted
into libxl that was 30% slower than the kernel one", I would
personally say "absolutely" (that is, if it came to a discussion, I
would argue for it).  As David says, not relying on the kernel is
reason enough to accept it.  The performance only needs to be good
enough to be usable (i.e., the performance threshold for acceptance
would be a lot lower than the numbers you've shown here).

Do note that just because SuSE has abandoned the kernel path doesn't
preclude others from either using old "classic" kernels, or
forward-porting (and trying to push) the PV backends themselves.  If
the kernel support shows up in libxl before the qemu backend is ready,
there's no reason to remove it until it's pretty clear that pvusbback
is well and truly dead.

 -George

Re: pvUSB backend performance

[Juergen Gross]

On 07/02/2015 06:41 PM, George Dunlap wrote:
> On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross <jgross@suse.com> wrote:
>> On 06/29/2015 03:22 PM, George Dunlap wrote:
>>> 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.
>
> So if you're asking for general advice about where we think you might
> best spend your time, I don't have much of an opinion; I don't know
> who your users are nor what your priorities are as a company.
>
> If you're asking, "Would support for a qemu pv backend be accepted
> into libxl that was 30% slower than the kernel one", I would
> personally say "absolutely" (that is, if it came to a discussion, I
> would argue for it).  As David says, not relying on the kernel is
> reason enough to accept it.  The performance only needs to be good
> enough to be usable (i.e., the performance threshold for acceptance
> would be a lot lower than the numbers you've shown here).

Thanks, that was the the kind of answer I'd like to receive.

> Do note that just because SuSE has abandoned the kernel path doesn't
> preclude others from either using old "classic" kernels, or
> forward-porting (and trying to push) the PV backends themselves.  If
> the kernel support shows up in libxl before the qemu backend is ready,
> there's no reason to remove it until it's pretty clear that pvusbback
> is well and truly dead.

Sure.

Juergen