Bug 659455

Summary: General response to input in VMs is very sluggish, high CPU usage by virt-manager, getting more sluggish and higher over time
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: gtk-vncAssignee: Daniel Berrangé <berrange>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: berrange, crobinso, mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-02 20:54:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adam Williamson 2010-12-02 20:25:02 UTC
In current Rawhide and updated F14, VMs feel much more sluggish in response to input than they used to; cursor movement is slightly lagged and jerky, it's slow to render new windows and so on. If it's just running some kind of task which doesn't involve input or redrawing, though, that seems to run much as normal, not slower.

When I'm doing stuff involving input or redrawing in the vm, I notice virt-manager taking a large amount of CPU time, and this gets larger and larger as time goes on (and the sluggishness observed gets more pronounced at the same rate). Right now, for instance, just moving a cursor around the desktop in an F13-on-F15 VM causes virt-manager to hit over 50% CPU usage on a pretty beefy system (Core 2 Quad at 3.4GHz).

crobinson suspects, and https://bugzilla.redhat.com/show_bug.cgi?id=657542 rather suggests, that this may be another problem with the major changes in gtk-vnc between 0.4.1 and 0.4.2. After I've finished the current operation in this VM, I'll try downgrading gtk-vnc to a 0.4.1 build and see how that goes.

Comment 1 Adam Williamson 2010-12-02 20:54:16 UTC
looks like dupe...

*** This bug has been marked as a duplicate of bug 657847 ***