On 04/05/2010 12:53 AM, Paul Brook wrote:
Surprising as there are ~10 descriptors being
polled, so ~1200 polls per second. Maybe epoll will help here.
I'm not sure where you get 1200 from. select will be called once per host
wakeup. i.e. if the USB controller is enabled then 1k times
Avi Kivity a...@redhat.com writes:
On 03/02/2010 11:34 AM, Jernej Simončič wrote:
On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote:
I remember about a year ago, someone asserting on the list that -usbdevice
tablet was very CPU intensive even when not in use, and should be avoided if
Looks like the tablet is set to 100 Hz polling rate. We may be able
to get away with 30 Hz or even less (ep_bInterval, in ms, in
hw/usb-wacom.c).
Changing the USB tablet polling interval from 10ms to 100ms in both
hw/usb-wacom.c and hw/usb-hid.c made no difference except the an increase
On 04/04/2010 05:25 PM, Paul Brook wrote:
Looks like the tablet is set to 100 Hz polling rate. We may be able
to get away with 30 Hz or even less (ep_bInterval, in ms, in
hw/usb-wacom.c).
Changing the USB tablet polling interval from 10ms to 100ms in both
hw/usb-wacom.c and
The USB HID devices implement the SET_IDLE command, so the polling
interval will have no real effect on performance.
On a Linux guest (F12), I see 125 USB interrupts per second with no
mouse movement, so something is broken (on the guest or host).
Turns out to be a a bug in the UHCI
My guess is that the overhead you're seeing is entirely from the USB host
adapter having to wake up and check the transport descriptor lists. This
will only result in the guest being woken if a device actually responds
(as mentioned above it should not).
A quick profile on the host side