On 11/09/10 00:03, Avi Kivity wrote:
On 09/10/2010 06:03 PM, Michael Tokarev wrote:
Strange. Can you also post a few lines of 'vmstat 1'?
Maybe we'll see a lot of context switches in there.
Not that many. Still running the same w7 guest, still
~25..27% CPU usage reported by top for the kvm process,
here's `vmstat 5' after a while (I tend to use larger
delay to mitigate large(ish) spikes):
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 286764 1262976 20640 1618468 0 0 0 24 6206 4460 7 9 84 0
1 0 286764 1263040 20640 1618436 0 0 0 0 6080 4415 7 9 84 0
1 0 286764 1264380 20648 1618448 0 0 0 5 6332 4576 8 11 81 0
1 0 286760 1264700 20656 1618436 6 0 6 18 6464 4742 7 8 84 1
1 0 286760 1264864 20664 1618472 0 0 0 10 6266 4704 8 8 85 0
0
Stumped.
A shot in the dark: can you try running with vnc instead of sdl (and disconnecting your vnc client
while measuring)? Maybe the guest is doing a lot of vga updates.
Just a data point. An idle XP guest for me without -usb sees the host running at about 8,000 context
switches a second. With the guest using -usb -usbdevice tablet, the host runs at between 15,000 -
18,000 context switches a second.
The descriptors show the device is requesting a polling frequency of 100Hz (0x0A ms), but don't
forget QEMU emulating a controller with a 1000hz microframe rate at worst.
There would probably be a lower load if the controller emulated was OHCI rather than UHCI just on a
reduction of required work by the Guest.
If you were prepared to tolerate a bit less responsiveness, you could always tweak the endpoint
descriptor to turn the polling frequency down.
0x0a, /* u8 ep_bInterval; (255ms -- usb 2.0 spec) */
I'm unclear as to where that comment came from. The usb 2.0 spec says a LOW_SPEED device can request
between 10->255 ms polling intervals. If the device is reporting as a HIGH_SPEED device, then all
bets are off.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
