> > I think the difference lies in several aspects: > > * During installation phase, most of the use it single-threaded and there's > > a lot of IO. During post-install, there are some tasks which are > > multithreaded (e.g. selinux policy compilation? some gzipping?) and the IO > > is lighter or none at all during some time periods. That explains why my > > host system is much more hogged during the end of the installation. > > * With the spinner on, not only qemu uses 200-240% CPU all the time, but I > > also see 30-45% CPU consumed by virt-manager, 25% CPU by Xorg and 10-15% > > CPU by gnome-shell. I assume this is caused by an extreme number of > > (probably full-screen) image redraws submitted by the VM, which in turn > > are submitted by metacity running inside the VM. If you compare this with > > the run with spinner off, virt-manager+Xorg+gnome-shell CPU consumption is > > basically zero. > > OK, if you close the vm window (it continues running in the > background) ... does the (host) system feel faster? Definitely. virt-manager, Xorg and gnome-shell processes on host immediately drop to almost 0%. The qemu process still consumes an excessive amount of CPU time (as compared to the spinner off case). So closing the VM window helps with the host, but not with the guest. The average installation time is then around 5m 40s. As for the guest performance, I used 'sshd' option to connect to netinst and watch the CPU usage using `top` throughout installation. * When the spinner is animated, Xorg consumes 50% CPU. * If I close the VM window, it drops to 40%. * If I open the window again, but switch the VM to TTY2 (text mode), it drops to 25%. * If I go back to TTY6 (graphical mode) and open the root password spoke, which makes the spinner disappear temporarily, the usage goes to 0% (!). * When I close the root password spoke and the spinner appears again, it again consumes 50%. * During certain periods of post-installation phase (especially to the end), the Xorg usage climbs up to 90% and holds steady for a minute or two. The changes are immediate and reproducible (at least here). > > > If you add up all the numbers in case of animated spinner, consider that I > > have just 2 physical CPUs (and the other 2 are just hyperthreading), and > > imagine I'm trying to browse some ajax-heavy website at the same time, no > > wonder that my system is completely trashed. > > Well the scheduler is supposed to be smarter then that the VM runs > inside its own cgroup as does your user session. Each one should get > an equal CPU share .. so I think the problem is that the drawing > inside the VM affects the host (by having the VM window open/visible). I kind of need it visible, when testing :-) But yeah, the impact of just displaying VM window seems to be extremely high (that's probably a second problem somewhere in the stack, but I don't think it's directly related to the spinner issue causing huge Xorg CPU usage). -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
