qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?


From: Michael Tokarev
Subject: Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?
Date: Wed, 17 Oct 2012 13:15:35 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7

On 17.10.2012 12:56, Gerd Hoffmann wrote:
> On 10/17/12 10:41, Michael Tokarev wrote:
>> Hello.
>>
>> I noticed that "some" versions of linux guests shows quite
> 
> What is "some"?

I guess it is almost all modern distros.  Debian wheezy,
Ubuntu 12.4, current Fedora (17 I think) to name some.

>> As far as I can see, this rule is to reduce polling interrupt
>> frequency, but apparently it does not help: any usb device
>> connected to guest, and the host CPU usage rises anyway, with
>> or without this rule.
> 
> No, it is for suspending the usb bus, so qemu stops doing 1000 wakeups
> per second when the usb tablet is idle.  Works only in case all devices

This is very close to what I guessed, so I don't see why "No" ;)

> on the usb bus support it, but for the typical usb use case (-usbdevice
> tablet for the abs ptr) this is the case.

My command line:

  qemu-kvm -drive file=linux.img,if=virtio -usbdevice tablet

(plus a few other unrelated options).  That to say, there's nothing
more than just one usb tablet, it is exactly the case mentioned
above.

And indeed, the CPU utilization drops from - on my host - 12% to about
1.2% after a few secs of mouse being idle in the guest.  So I was
wrong here, and it actually works - it does what it was supposed to
do, it reduces CPU usage.

But the mouse is jumpy anyway.  I guess one can get used to this
behavour, given the tradeoff and that the behavour is not VERY annoying --
it is annoying, but just for a "bit", it feels like old mechanical
mouse with bad sensor or dirty ball when you can move the mouse but
cursor sometimes stays in place and sometimes moves, depending on
the surface and direction of the move... ;)

> No.  We should fix whatever is broken.

Is it _ever_ possible to fix this?

What happens when the (device, bus) is suspended?  Does host still
sends interrupts periodically (but with much lower frequency)?  Or
is it the bus/hub/device which should signal attention at some point?

Sorry I'm not even a novice in USB internals ;)

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]