Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-05 Thread Avi Kivity
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

High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-04 Thread Chris Webb
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

Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-04 Thread Paul Brook
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

Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-04 Thread Avi Kivity
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

Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-04 Thread Paul Brook
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

Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)

2010-04-04 Thread Paul Brook
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