From: Michael Tokarev <mjt@tls.msk.ru>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?
Date: Wed, 17 Oct 2012 13:15:35 +0400 [thread overview]
Message-ID: <507E7737.8030207@msgid.tls.msk.ru> (raw)
In-Reply-To: <507E72B3.2010003@redhat.com>
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
next prev parent reply other threads:[~2012-10-17 9:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 8:41 [Qemu-devel] udev 42-qemu-usb.rules considered harmful? Michael Tokarev
2012-10-17 8:56 ` Gerd Hoffmann
2012-10-17 9:15 ` Michael Tokarev [this message]
2012-10-17 9:21 ` Michael Tokarev
2012-10-17 10:58 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=507E7737.8030207@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.